Re: Dumbed-down
Greg Herlihy wrote:
James Kanze wrote:
Greg Herlihy wrote:
> "Krzysztof Zelechowski" wrote:
>> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
>> news:1153126683.242065.284470@35g2000cwc.googlegroups.com...
>>> "Krzysztof Zelechowski" wrote:
>>>> assert(Target(x) == x);
>>> You may get an implementation defined signal before the
>>> assert trips (which probably doesn't matter). You may
>>> also fail to trip even when you should, if the
>>> conversion is between signed and unsigned types, e.g.
>>> Target is unsigned int, Source is int, and the value of
>>> x is -3.
>> My code should be used when the compiler issues a
>> warning. Should there be a warning about an implicit
>> cast from int to unsigned int, my code would fail. But
>> the OP wanted to handle a warning about truncation.
> It is also possible when converting from one numeric type
> to another to have an assertion detect either value
> truncation or a signed/unsigned value mismatch between
> the original and converted value. The key is to have the
> assertion perform the comparison with a numeric type of
> sufficient range and resolution to resolve the inequality
> (in other words, a long double):
> typedef long double LongDouble;
> ...
> assert( LongDouble(x) == LongDouble( Target(x)));
The whole point of the verifications is to avoid doing
Target(x), which may have implementation defined behavior,
and in fact core dumps for some values and some Target types
on may systems.
Then the concern is overblown. As long as Target(x) is not
undefined, than the expression is perfectly safe and will have
either an implementation-defined or a well-defined value - (in
no event would it ever have implementation-defined
"behavior").
That's not what the standard says. The C++ standard is rather
vague about what could happen, but the C standard is very clear:
either an implementation defined value, or an
implementation-defined signal.
In practice, I suspect that on most modern implementations, it
will depend on the settings of the FPU: C99 requires the
presence of an option for trapping, and it would be surprising
if implementations of C++ didn't offer it as well.
Furthermore, while a program could test
numeric_limits<Target>::traps to determine whether the Target
type traps at all, it is not even necessary in this case.
There is no chance that initializing a Target type with a
valid numeric value could ever trap - since only arithmetic
operations can trap.
The standard says differently. At least, it says that the
conversion may raise an implementation defined signal.
Initialization is not an arithmetic operation.
After all, if 70 lines of highly specialized template code are
needed just to determine whether converting a floating point
to integer value wouldn't core dump in C++, who in their right
mind would ever decide to write a numerical program in C++?
Maybe those who understand the language, and know how to use it
for there applications. Or those who want the machine to trap
on an error condition. If you know the types involved, it's
very easy to write the code. The problem is to write it
generically without knowledge of the types, and correctly handle
all of the oddities concerning unsigned and signed comparisons
and promotions.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]