Re: [Boost-users] problems with C++ integer types

Subject: Re: [Boost-users] problems with C++ integer types
From: Daryle Walker (darylew_at_[hidden])
Date: 2012-01-31 03:09:46

I haven't yet read the Usenet article you mentioned in your reply because I want to get out my initial response without influence.
[I read it after writing the following.  I think my post here is more useful.]

----------------------------------------
> From: Robert Ramey
> Date: Sun, 29 Jan 2012 15:01:10 -0800
>
> I'm very confused about a number of things related to C++ standard and boost
> libraries
> dealing with numeric types. Here are a few things that I'm not getting.
>
> a) The standard says in section 18.3.2.1
>
> "Specializations shall be provided for each arithmetic type, both floating
> point and integer, including bool.
> The member is_specialized shall be true for all such specializations of
> numeric_limits."
> ...
> "Non-arithmetic standard types, such as complex<T> (26.4.2), shall not have
> specializations."
>
> and it section 18.3.2.4 numeric_limits members
>
> static constexpr bool is_bounded;
>
> "True if the set of values representable by the type is finite. [ Note: All
> built-in types are bounded.
> This member would be false for arbitrary precision types.-end note ]"
>
> So the question is: if one makes a "numeric type" like std::complex (or safe
> integer
> which I'm interested in right now). Should one define a specialization for
> this new type?

In my opinion, the qualifier is if the numeric concept is a (sub)set of the real numbers.  If so, then they should have a std::numeric_limits specialization.  Your UDT could even have conversions or other interactions with the built-in numeric types.

Built-in floating-point: YES
Built-in integers (signed or unsigned): YES
Built-in characters or Boolean: Logically, NO.  Actuality, YES, due to the C++ language defining them as integer types.  (And they're usable as such.)
UDT arbitrary integer: YES
UDT arbitrary floating/real: YES
UDT rational: YES
UDT arbitrary continued-fraction rational/real: YES

Complex: NO
Modulo: NO
Polynominals: NO
(Math) Vectors: NO
Matrices: NO
Geometry: NO

Real numbers can somehow map to some of my "NO" types, but reverse is sane only in degenerate cases (0 imaginary part; degree of 0, 1-element vector, 1x1 matrix), so they don't get numeric-trait specializations.  (Many of these can support a zero vs. non-zero dynamic, but make any operator-bool explicit!)

>
> The working is pretty specific, but then I can't see why "is_bounded" is in
> there since
> all built-in arithmetic types are bounded. Oh I see this now: Required by
> LIA-1.

Is-bounded wouldn't apply to arbitrary length/precision types.

>
> b) boost/type_traits/is_integral.hpp
>
> This file just specializes each arithmetic type supported by the
> implementation.
>
> question:Why isn't it just implemented in terms of numeric limits so that
> every
> thing is always consistent and never "out of sync" It's implementation
> returns
> true for only the built in types so it seems to me it should be repeating
> what
> ever happens to already be in numeric_types.

numeric_limits is for the type's math properties.
is_integral is for the type's properties with respect to the C++ type system.  It can be used for template meta-programming.

>
> c) my real interest is to implement a type "safe_integer" which can be
> used anywhere an integer is used but will trap errors which occur in
> the course of implicit conversions and assignements. If I don't specialize
> numeric_limits for my new "safe_integer" certain type_traits like is_signed
> won't work for it. If I do - them I"m out of sync with is_integral.hpp and
> likely out of conformance with the standard - though I'm not sure what the
> implications of that might be.
>
> I'm aware that there is related work going on here - bigint and arbitrary
> length integers. How do the authors of these libraries plan to address
> this.
>
> There are other cases applications where this would also come up
> such as modular integer<modulus> , safe_integer_range<max, min>
> and who know what else.
>
> Any useful information/insight would be appreciated.

The "modular integer<modulus>" is the only one of these that should NOT get a specialization for numeric_limits.  All of the others conceptually represent real-number values, and therefore should.  None of these types are built-ins, and therefore NEVER should get a is_integral specialization.

Daryle W.