
Boost Users : 
Subject: Re: [Boostusers] problems with C++ integer types
From: Daryle Walker (darylew_at_[hidden])
Date: 20120131 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."
> ...
> "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?
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 builtin numeric types.
Builtin floatingpoint: YES
Builtin integers (signed or unsigned): YES
Builtin 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 continuedfraction 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, 1element vector, 1x1 matrix), so they don't get numerictrait specializations. (Many of these can support a zero vs. nonzero dynamic, but make any operatorbool explicit!)
>
> 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.
Isbounded 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 metaprogramming.
>
> 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 realnumber values, and therefore should. None of these types are builtins, and therefore NEVER should get a is_integral specialization.
Daryle W.
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