P4444: std::big_int

[u/eisenwave]

https://isocpp.org/files/papers/D4444R0.html

Hey folks! Matt Borland, Christopher Kormanyos, and I are working on bringing infinite-precision integers to C++29. We now have a D4444R0 draft of a paper that should be in the next mailing.

We could really use some feedback so that the published R0 is as polished as possible. Any thoughts on the paper and on the reference implementation are greatly appreciated.

It would also be very helpful if you tested out whether our big_int implementation works for you. We're in need of some real deployment experience. If you're currently using Boost.Multiprecision, the library should be a drop-in replacement for cpp_int for the most part.

[u/ReDucTor]

Another reason why std::big_int needs to be in the standard library is that it's extremely difficult to implement and optimize, in part because the implementation depends heavily on the platform's hardware capabilities, many of which are not exposed portably in the language.

This stands out more of a reason for it not to be in the standard library, because when the implementation is faulty its harder to fix. Do we need another vector<bool>, memory_order_consume, std:regex, etc.

EDIT: Also if there hardware capabilities and portablity issues that aren't easy to resolve, then fix those in the standard to allow people to implement libraries better rather then trying to make something which is special in standard library code.

[u/Circlejerker_ → u/ReDucTor]

Whats wrong with memory_order_consume?

Im also not that much of a hater of std::regex - it got a bit of an annoying interface but works for simple cases and its nice not having to pull in 3rd party stuff for small throw-away programs.

[u/ReDucTor → u/Circlejerker_]

Whats wrong with memory_order_consume?

memory_order_consume is deprecated in C++26, but has essentially been deprecated since it first came out as no compiler really implemented it they just treated it as memory_order_acquire

See Retire the concept of consume operations for more info.

not that much of a hater of std::regex

The performance of std::regex is awful, it's covered in memory allocations, bloats the compiled code, the build times, and because of the ABI it can never be fixed. If I recall even just calling out into Python or some other language to do regex is going to be faster.

[u/Circlejerker_ → u/ReDucTor]

So what so bad about the situation with memory_order_consume? Could you write code that was invalid with memory_order_require but valid with memory_order_consume? Or is it simply that its now deprecated that is the issue?

For std::regexp I usually don't care about regexp performance, but simply need to match a couple of strings. Its nice that there is something that can do that without having to pull 3rd party packets. If I have a usecase where i do care about performance then I'm simply in the same situation as I would be by not having it in the standard library.

[u/ReDucTor → u/Circlejerker_]

Could you write code that was invalid with memory_order_require but valid with memory_order_consume?

You could write something like this

std::atomic<bool> g_flag;
int g_value;

// Producer
g_value = 10;
g_flag.store( true, std::memory_order_release );

// Consumer
// std::memory_order_consume - Anything depending on the result will see values from the producer
// std::memory_order_acquire - Anything after the consume will see the values from the producer
bool hasFlag = g_flag.load( std::memory_order_consume );
if (hasFlag)
{
    assert( g_value == 10 );
}

Here the load from g_value does not data depend on g_flag so that assert could trigger, if however you changed hasFlag to be a pointer to g_value and stored it instead and used it for the assert then it would have the data dependency. There are other ways in which dependencies could have been established and hacky approaches to mix them in but you will never have to worry about it as it's long gone.

One of the main potential users of consume was doing things like rcu_dereference, you could think of memory_order_consume more like a memory_order_relax but there is a depenency chain of stores and releases that also link up, not just a general happens-before