czw., 2 kwi 2026 o 11:42 Jan Schultke <janschultke_at_[hidden]> napisał(a):
>>
>> > 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.
>

but it will work the same in normal unshared heap allocation.
Only copy differs as one need always call local thread allocator where
other trash shared cache to bump ref count. But in shared you still
need to allocate when you try to update local value (and trash shared
cache again).

If I would need to guess I would prefer the local version, but this
would need some benchmarking.


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