Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
- From: "Igor Tandetnik" <itandetnik@xxxxxxxx>
- Date: Sat, 28 Mar 2009 09:52:03 -0400
"KD" <keith.degrace@xxxxxxxxx> wrote in message
news:18e21a9c-8a99-48a1-8744-1c07478b737d@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
I was expecting consistent results between VS2003 and VS2008. I
understand this is undefined behavior in the holy standard, but take
this bit from Stroustrup's FAQ: "Note that many "things" that people
refer to as "undefined" are in fact "implementation defined", so that
we can write perfectly specified code as long as we know which machine
we are running on. Sizes of integers and the rounding behaviour of
floating-point computations fall into that category." I thought maybe
numeric cast overflow fell into this category for MSVC.
You seem to misunderstand the note. Some things in the standard are
declared implementation-defined, e.g.
4.8p1 An rvalue of floating point type can be converted to an rvalue of
another floating point type. If the source value can be exactly
represented in the destination type, the result of the conversion is
that exact representation. If the source value is between two adjacent
destination values, the result of the conversion is an
implementation-defined choice of either of those values. Otherwise, the
behavior is undefined.
Others are undefined:
4.9p1 An rvalue of a floating point type can be converted to an rvalue
of an integer type. The conversion truncates; that is, the fractional
part is discarded. The behavior is undefined if the truncated value
cannot be represented in the destination type.
So, a behavior is either implementation-defined, or undefined. It's
meaningless to say "maybe the behavior is implementation-defined for
this particular implementation, even if it's undefined elsewhere."
In his note, Stroustroup simply points out that people in informal
conversations often lump undefined and implementation-defined behavior
together, even though there is a difference. Unfortunately, yours is not
the case of this mistaken identity, but an honest-to-God instance of
undefined behavior.
For completeness, here's the definition of the relevant terms:
1.3.5 implementation-defined behavior [defns.impl.defined]
behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation shall
document.
1.3.12 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct
or erroneous data, for which this International Standard imposes no
requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition
of behavior.
1.3.13 unspecified behavior [defns.unspecified]
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
.
- Follow-Ups:
- References:
- Prev by Date: Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
- Next by Date: Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
- Previous by thread: Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
- Next by thread: Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
- Index(es):
Relevant Pages
|