4 ms·

C++ can have arbitrary-width integers as library types; it would not be that big of a deal IMHO. If `optional`, `variant` and `any` (and maybe soon, `bit`) are

C++ can have arbitrary-width integers as library types; it would not be that big of a deal IMHO. If `optional`, `variant` and `any` (and maybe soon, `bit`) are not in the language itself, no reason why n-bit-integer should be. (Of course, this is written from the "we can jerry-rig the existing language to do what you want" perspective with which so much is achievable efficiently in C++.)

nabla9 7y ago
> no reason why n-bit-integer should be. If standard is agreed, it could be pragma similar to calling conventions.
hermitdev 7y ago
Boost Multiprecision [0] is an example of such a library type. It offers a compile-time arbitrarily wide integers (with predefined types up to 1024 bits) and a C++ wrapper around the GMP or MPIR libraries, which supports arbitrary sizes at runtime (not sure how it's implemented, but probably on top of an array of ints or BCD (binary-coded decimals)). C++ has had `optional` and `variant` since (I think) C++11, maybe 14. I don't think `any` made the cut. All of these types originated (for C++ standardization) in Boost, as well. I'd caution against using `any`, though. From personal experience, the runtime overhead is quite high, and holding any non-none type is a dynamic allocation. Performance is far better with `variant` at the development cost of needing to know all the types you're going to support at compile-time. [0] https://www.boost.org/doc/libs/1_72_0/libs/multiprecision/doc/html/index.html https://www.boost.org/doc/libs/1_72_0/libs/multiprecision/do...
- einpoklum 7y ago
  optional and variant are new in C++17, actually. They were experimental in 14. But - in a sense, C++ still doesn't "have" them, since basically nothing in the standard library relies on the availability of any of these. (And - I also try to avoid std::any)

4 ms·

C++ can have arbitrary-width integers as library types; it would not be that big of a deal IMHO. If `optional`, `variant` and `any` (and maybe soon, `bit`) are

by einpoklum 7y ago

nabla9 7y ago
> no reason why n-bit-integer should be. If standard is agreed, it could be pragma similar to calling conventions.
hermitdev 7y ago
Boost Multiprecision [0] is an example of such a library type. It offers a compile-time arbitrarily wide integers (with predefined types up to 1024 bits) and a C++ wrapper around the GMP or MPIR libraries, which supports arbitrary sizes at runtime (not sure how it's implemented, but probably on top of an array of ints or BCD (binary-coded decimals)). C++ has had `optional` and `variant` since (I think) C++11, maybe 14. I don't think `any` made the cut. All of these types originated (for C++ standardization) in Boost, as well. I'd caution against using `any`, though. From personal experience, the runtime overhead is quite high, and holding any non-none type is a dynamic allocation. Performance is far better with `variant` at the development cost of needing to know all the types you're going to support at compile-time. [0] https://www.boost.org/doc/libs/1_72_0/libs/multiprecision/doc/html/index.html https://www.boost.org/doc/libs/1_72_0/libs/multiprecision/do...
- einpoklum 7y ago
  optional and variant are new in C++17, actually. They were experimental in 14. But - in a sense, C++ still doesn't "have" them, since basically nothing in the standard library relies on the availability of any of these. (And - I also try to avoid std::any)