Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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++.)



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/do...


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)


> no reason why n-bit-integer should be.

If standard is agreed, it could be pragma similar to calling conventions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: