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

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 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.