
Boost Users : 
Subject: [Boostusers] problems with C++ integer types
From: Robert Ramey (ramey_at_[hidden])
Date: 20120129 18:01:10
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."
...
"Nonarithmetic 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
builtin 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?
The working is pretty specific, but then I can't see why "is_bounded" is in
there since
all builtin arithmetic types are bounded. Oh I see this now: Required by
LIA1.
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.
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.
Robert Ramey
Boostusers list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net