C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Why is is_bounded != false required for digits10, but not for digits?

From: Ivan Matek <libbooze_at_[hidden]>
Date: Mon, 31 Mar 2025 21:15:04 +0200
minor correction to my original message.

I have messed up when doing comparison between cpp_int and gmp_int in
boost. gmp_int is a backend, not a type. :)
https://www.boost.org/doc/libs/1_87_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/gmp_int.html
If anything it proves would be nice to detect this kind of mistakes at
compile time.

This mistake does not affect my general question, but in case anybody is
reading this in the future I don't want them to have wrong information.

On Sat, Feb 15, 2025 at 5:28 AM Ivan Matek <libbooze_at_[hidden]> wrote:

> Hi everybody,
> I may be misunderstanding something so first brief recap, then my question.
>
> Current https://eel.is/c++draft/numeric.limits and C++26 draft say this:
>
> static constexpr bool is_bounded;
> true if the set of values representable by the type is finite.
> [Note 3: All fundamental types ([basic.fundamental]) are bounded. This
> member would be false for arbitrary precision types. — end note]
> Meaningful for all specializations.
>
> Makes sense, it is important to know if type has infinite or finite number
> of values it can represent(here we obviously ignore fact of finite memory,
> etc).
>
> But there is weird difference between digits and digits10 in terms of
> requirements:
>
> digits:
> (no requirements)
> digits10:
> Meaningful for all specializations in which is_bounded != false.
>
>
> I find this confusing. In my mind only difference between the two is
> scaling factor and rounding. In other words:
> T has supports for infinite digits ⇒ T has support for infinite digits10
>
> so same requirement should apply for digits(i.e. that is_bounded !=
> false).
>
> If somebody is interested I checked what boost multiprecission reports and
> seems a bit inconsistent between cpp_int and gmp_int.
> https://godbolt.org/z/n19sYxvdq
> but in any case it is not super important since this is question about the
> standard.
>
>

Received on 2025-03-31 19:15:19