Boost Users :
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
> dealing with numeric types. Here are a few things that I'm not getting.
> a) The standard says in section 126.96.36.199
> "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
> "Non-arithmetic standard types, such as complex<T> (26.4.2), shall not have
> and it section 188.8.131.52 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
> 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
(Math) Vectors: 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
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
> question:Why isn't it just implemented in terms of numeric limits so that
> thing is always consistent and never "out of sync" It's implementation
> true for only the built in types so it seems to me it should be repeating
> 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
> 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.
Boost-users 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