On 4/2/26 10:32, Jan Schultke via Std-Proposals wrote:
> * Perform reference counting (and copy on write) for the dynamic representation. This has key benefits:
> o std::big_int would typically be passed by value because it is cheaply copyable and cheaply movable, which is really natural in mathematical code. It also means there is no need to pass std::big_int by forwarding reference or to add extra rvalue overloads to avoid extra allocations. Whenever a function is given a std::big_int by value, it can check the reference counter and repurpose the allocation if it holds the sole reference.
> o It is possible to implement abs like (x < 0 ? -x : x) without dynamic allocation. Negation is just creating a reference-counted copy with the sign bit flipped.
> o std::big_int can be cheaply returned by value from a function by a getter. If the class of the getter holds an int, it can create a std::big_int without allocating thanks to SSO. If it holds a std::big_int internally, it can cheaply copy that std::big_int. By comparison, returning a const std::string& or std::string_view from getters leaks internal representation details of classes.
>
>
> One design aspect I'm not so sure about is whether std::big_int would be allocator-aware and whether the "limb type" should be configurable. If neither of these is true, it could be a non-templated class, which is attractive.

 - For consistency, we will want configurable allocators; we have them
everywhere, even though the "common" vocabulary type uses a default
(cf. std::string).

 - gcc's reference-counted string failed at least on the front of
not being able to satisfy the standard's requirements on simultaneous
use across threads, if I remember correctly. It also took a while
to actually get all the places right where an "unshare" operation
was needed. Since users won't be able to look at the elementary
items composing a big_int, that's probably less of an issue.

 - For a reference-counted big_int, we need a multi-threading story:
Do we do atomic reference counting? If so, that's a dead end for some.
If not, creating two copies of a value in two different threads fails,
which is not in harmony with the standard library's expectation of
multi-thread compatibility.

 - Can we get the core algorithms (operating on byte streams or so),
independent of the memory management concerns?

Jens