<[EMAIL PROTECTED]> wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C45CF@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45CF@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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost