sob., 1 sie 2026 o 03:09 Jamie Allsop via Boost <boost@lists.boost.org> napisał(a):
Hi Arnaud,
A very late and very short review.
On 22/07/2026 12:37, Arnaud Becheler via Boost wrote:
Other questions you might want to answer in your review are: - What is your evaluation of the design?
It looks good, solves a genuine problem and we would probably update our codebase to use it.
- What is your evaluation of the implementation?
I only took a brief look but it seemed to be of high quality, written by someone who knows the subject matter.
- What is your evaluation of the documentation?
The documentation was comprehensive and informative.
- What is your evaluation of the potential usefulness of the library?
It solves a real use case in several domains that the docs list at the start. We are in a least one of those.
- Did you try to use the library? With what compiler? Did you have any problems?
I did but as we use a pattern like this in our code:
enum class big_quantity : int128_type { none = std::numeric_limits<int128_type>::max() };
which of course doesn't work with this type so it was not useful.
This is interesting. It shows why a library solution will never be a full substitute for a built-in type. For a similar reason, it would be a bad idea for this library implementation to fall back to an alias on a built-in type on platforms where it is available, as then users would not be able to reliably depend on being able to derive from the type to make extensions. Regards, &rzej; However I could potentially create a derived class that has the same
benefit possibly (I want a named integer type) but then I'd have to rewire a bunch of other stuff. I did enough to see that we could potentially have this work but it was too much effort for this review.
I was using gcc15.3 btw.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A couple hours only. It's a 128bit integer.
- Are you knowledgeable about the problems tackled by the library?
We use __int128 in our codebase for exactly the reasons listed in the rationale but sadly this would not be a trivial drop-in replacement but I could see how it might be useful if we needed it. We do need an int256 type that's lightweight and performant and if we had that I could see us using this as well as for that it would be worth working out the (extensive) reworking of the enum pattern.
That said I think this library is a valuable addition (but int256 would be even more useful ;-)) so I vote to ACCEPT the library. Jamie
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/VYUXW3KW...