Re: [boost][int128] Formal Review Begins Today (July 22-July 31)

Thank you Arnaud for coordinating this review process.

Boost.Int128 is appealing for certain applications that require larger
magnitude integers than provided by int32_t or int64_t.
I have sometimes used multiprecision libraries in the past, but fixed-size
storage is often preferred for array storage and performance reasons.
I do also think Boost.Int128 could form a basis for eventual formal C++
language support, although perhaps fairly niche.
(C++ is already large and multi-paradigm, so why not?)
The portability of Boost.Int128 is very appealing, especially across gcc,
clang and microsoft toolchains.
It's super-nice that std::format works, for example.

I have spent a few hours of my after work time reading parts of the
documentation and applying this to some old PhD code of mine.
I've had success with a constexpr (wasn't before) table-based factorial
implementation supporting uint32_t, uint64_t and Boost.Int128.
In the course of that I also came across some of my own bugs from years ago
which were easily clarified and resolved with the help of Boost.Int128.
(I can now run in any of the three modes to confirm that 64-bit is
sufficient or not, nice)

One minor quibble I had with the documentation.
The examples section has a prominent section for libfmt, but I felt that
std::format should be at least as prominent.
I was of course reassured to find std::format mentioned in the reference
section, and it worked just fine, so all good there.

A minor gap I came across was C++23 std::byteswap and related
endian support.
Less of a practical concern nowadays, but it would be nice for Boost.Int128
to "just work" there too.

It seems necessary to use BOOST_INT128_UINT128_C macro to initialise a
std::array<boost::int128::uint128_t,
35>.
A C++ language constraint?  Certainly could be me doing it "wrong".  (But
it works)

I recommend to ACCEPT Boost.Int128, it is a worthwhile addition to the
boost toolbox, and documented and implemented to a high standard.

  - What is your evaluation of the design?
>

Provides a native-like type for both signed and unsigned 128 bit integers.
Seems like the obvious and correct approach.
My array of uint64_t would be twice as much RAM, but still a single malloc.


>   - What is your evaluation of the implementation?
>

Well structured.  Didn't have any trouble enabling std::format, iostream or
literals.


>   - What is your evaluation of the documentation?
>

Nice modern formatting and detailed enough presentation.
Tone is appropriate, not quirky or overly opinionated.


>   - What is your evaluation of the potential usefulness of the library?
>

Useful to me, depending on the problem domain.
Would have been all over it as a PhD student, for sure.


>   - Did you try to use the library? With what compiler? Did you have any
> problems?
>

I used gcc 13.3.0 with -std=c++23 and -Wall flags.
I refactored some old code to extend it for 128 bit arithmetic.
My quick ad-hoc testing showed the same expected output for both 64-bit and
128-bit modes.


>   - How much effort did you put into your evaluation?


A few hours of trying things and thinking about use cases.
It ticked all the more obvious boxes, in terms of day-to-day work.
Such as "will spdlog freak out?  No, we're good".

  - Are you knowledgeable about the problems tackled by the library?
>

Part of my PhD was concerned with evaluating large exponents and factorials.
My recollection is that I needed to be careful to multiply and divide in a
sensible order.
I don't think I exceeded what can be done with 64-bits, but I was aware of
the potential for trouble.

My first thought with Boost.Int128 was to build a "really, really big" 3D
minecraft world.
Turns out that's billions times larger than the observable real-world
universe, at 1m granularity.
As a reference, Minecraft worlds are "only" 60,000km wide horizontally.

Large magnitudes can be challenging in geospatial domains.
64 bits seems sufficient to zoom (google maps style) all the way from
planetary to atomic scale.
Usually smaller integers are fine, but having 128 or even 256 within easier
reach, even better.
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/2I3I3MP5XJVOHYOFZB7XTB3H7O4H6Q7K/