On Wed, Jun 16, 2010 at 4:00 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
Integer implicit conversions specifically are very common in C and C++. For example, incrementing a short int results in two implicit conversions, one of which might lead to truncating the value. That is about as safe (or unsafe) as the code in question, so why nobody cares about that case? Answer: because the compiler doesn't warn.
No, it is because increment has well defined behavior for short that doesn't require a warning. The code in question could have generated -- but doesn't presently -- a value that wouldn't fit in the target type leading to a misinterpretation of the result.
AFAIK the semantics of incrementing a short are that its value is first implicitly converted to int, which is then incremented (as an int), and then the int result is truncated (assuming sizeof(short)<sizeof(int)) back to short. As far as warnings are concerned, shouldn't this be treated identically to the case when the truncated value was an int to begin with?
If you don't want your compiler to issue a particular warning, a type cast should be the last solution to reach for, IMO.
It certainly appears that the types can be adjusted to alleviate the problem in this case, but that isn't always possible as impedance mismatches occur that cannot be altered. In such cases, a static_cast, which *should* indicate that the developer examined the code in question and has decided that the potential for truncation is not an issue
Disabling the warning locally would indicate that the developer examined the code, but (importantly) the program remains unchanged. Using static_cast is not the same as disabling the warning locally; for example, if a future remote edit changes the type of the object being converted, static_cast may inhibit a compile error. Even more ill-advised is instead of static_cast<T>(x) to use the functional notation syntax T(x) which in some cases has the semantics of a C-style cast which is even more likely to inhibit a compile error. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode