Date: Thu, 2 Apr 2026 11:42:01 +0200
>
> > Perform small object optimizations, at least for up to 64 bits. In
> standardese, it should be possible to represent any standard signed or
> standard unsigned integer type as std::bit_int without having to perform
> memory allocation. This covers the common use case of merely using
> std::big_int for the eventuality that it is big, but rarely working with
> big values.
> > Perform reference counting (and copy on write) for the dynamic
> representation. This has key benefits:
> >
>
> wasn't this a flaw in GCC old `std::string`? When they move to C++11
> string it improves performance in some cases?
>
I'm not sure what you mean by "flaw" specifically here. Reference counting
as a technique for std::big_int makes sense even in C++11. Move semantics
allow you to also "steal" the handle to a reference counter from another
std::big_int, so they interop nicely with reference counting.
> Another thing, would this have the performance of `std::shared_ptr` as
> it needs to be thread aware?
Yes and no. Reference counting needs to take place atomically for the copy
constructor to be thread-safe. However, as long as your integers are small,
you never actually perform reference counting because of SOO.
> > Perform small object optimizations, at least for up to 64 bits. In
> standardese, it should be possible to represent any standard signed or
> standard unsigned integer type as std::bit_int without having to perform
> memory allocation. This covers the common use case of merely using
> std::big_int for the eventuality that it is big, but rarely working with
> big values.
> > Perform reference counting (and copy on write) for the dynamic
> representation. This has key benefits:
> >
>
> wasn't this a flaw in GCC old `std::string`? When they move to C++11
> string it improves performance in some cases?
>
I'm not sure what you mean by "flaw" specifically here. Reference counting
as a technique for std::big_int makes sense even in C++11. Move semantics
allow you to also "steal" the handle to a reference counter from another
std::big_int, so they interop nicely with reference counting.
> Another thing, would this have the performance of `std::shared_ptr` as
> it needs to be thread aware?
Yes and no. Reference counting needs to take place atomically for the copy
constructor to be thread-safe. However, as long as your integers are small,
you never actually perform reference counting because of SOO.
Received on 2026-04-02 09:42:15
