[boost] Re: Re: Re: proposal: safe arithmetic class

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-01-17 14:40:48

<Bjorn.Karlsson_at_[hidden]> wrote in message
news:3D8559AE95B4D611B02C0002557C6C8B3C45CF_at_STH-EXCH...
[snip]
>
> 1) Controlled numeric type promotion and conversion
> This would be needed for safe(r) expressions; the rules for integral
> promotions, floating point promotions, integral conversions, floating
> integral conversions, and the usual arithmetic conversions, would be
encoded
> explicitly in types or implicitly in expressions. Unary and binary
> expressions are handled to produce the correct resulting type; conversions
> that would lead to loss of precision or range are invalidated, either at
> compile time or runtime. It is probably a nontrivial task to find
consensus
> on what to allow; for example, should the special rules for unsigned
> arithmetic be prohibited or not? [No expression templates required here
> either, but could potentially simplify and add functionality to the
> implementation.]
>
> Example:
>
> Int i=std::numeric_limits<int>::max();
> Short s=7;
> UShort us=i+s; // i+s results in a type equivalent to unsigned int, and us
> is assigned "the least unsigned integer
> // congruent to the source integer (modulo 2n where n is the number of
bits
> used to represent the unsigned type)"
> // , i.e. it "wraps around". Should this be legal for this safe type?

My personal view would be that it should throw an exception.

> 2) Complex expression conversion and promotion control
>
> If the aforementioned mechanisms for controlling conversions and
promotions
> exist, there is still the matter of more "complex" arithmetic, involving
> intermediate steps. This is where the expression templates need to enter
the
> arena, because we can no longer simply evaluate the binary operations; we
> must consider the expression as a whole. If we don't, seemingly equivalent
> expressions will be treated differently (just as is the case with
> built-ins):
>
> int x=1000000;
> int y=1000000;
> int z=1000000;
>
> int r=x*y/z; // Probably a negative number, implementation-defined.
> safe_numeric throws an exception if all variables are safe_numeric.
> r=x/z*y; // 1000000. safe_numeric doesn't throw an exception.

As far as possible, a "safe numeric" is a type that never lead the user
into implementation defined behavior. For most of my programs I wouldn't
worry
about if it meant a slower type; program correctness should be the only
concern.

> I don't think all of the above was the intent of your proposal though?
no it wasn't. Of course, I also wanted a discussion because it is often not
as trivial
as I tend to think.

>(And
> also, there might be value in a partial solution for detecting
> errors/problems/strange results at runtime) The three problems stated
above
> seem to have great potential for solutions through class libraries (and
> unlimited precision types, where art thou?), and my point has been (and
is)
> that 0) is already covered by numeric_cast, and might not need another
> solution; the others remain open.

I think it might be hard to say if we need three levels of granularity.
Anyway, the important thing
is that there could be a need for more control of implicit
conversions/undefined behavior.

As I understand, there have been a proposal to include a recent C-standard
header which
defines int8_t, int32_t types (which are guarenteed to have the proclaimed
size) into C++ too.
Maybe these types could be defined with additional "safety" guarantees in
C++ so we could avoid
adding too many new names (it might be a bad idea if C programs compiled
with a C++ compiler must have
the same semantics).

regards

Thorsten