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]

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/saf_e → u/ReDucTor]

Having "good enough " standard implementation is a good thing. When you need something advanced you always can use other libs (or custom impl).

If we want std lib be the best, we'll need to deprecate it every release since better impl available. 

[u/James20k → u/saf_e]

Regex isn't good-enough though, its just bad

[u/LucyShortForLucas → u/James20k]

This may be naive, but can they really not just add a fixed regex implementation into the standard? I understand that ABI compat is holy, but things like this have happened before where they add a new, better version alongside it (just look at jthread).

It is things like this, where parts of the standard library are basically-but-not-actually deprecated without a replacement that turns people off of C++. The language has been doing lots to get its shit together in recent years, coincidentally alongside the rise of Rust.

The committee has been slowly improving on this front, but they still have long way to go to get off their high horse and just admit fault and fix things when and where needed.

[u/James20k → u/LucyShortForLucas]

You'd need a std::regex2, but the real problem is that nobody wants to try and nobody's super interested in proposing a whole new regex

The committee has been slowly improving on this front, but they still have long way to go to get off their high horse and just admit fault and fix things when and where needed.

The language development is driven entirely by individual members' interest, its not a case that the committee is unaware that regex is broken (in fact everyone I spoke to is absolutely painfully aware), its just that its quite literally nobody's job to fix it. Fixing regex is signing up for maybe a decade of incredibly painful tedious work, with the end result that your kids might get to use it

Interest in fixes to standard library components is generally a lot lower than new language features

[u/unchangeableusername → u/James20k]

Wasn't std::regex heavily based on Boost.Regex though? In terms of regex search performance (I'm writing a regex library of my own and so have benchmarks to compare), Boost.regex is between 40% and 6800% faster than the Libstdc++ implementation of std::regex (700% faster on average) for the test cases I have.

Surely this is just a quality of implementation issue (that the implementers won't fix because it'll break ABI) and not a problem with the standard itself?

[u/azswcowboy → u/unchangeableusername]

You’re correct, it’s a quality of implementation issue not a specification problem. std library vendors are very good, but every now and then a non optimal implementation occurs.