Re: [boost] [units] gcc warnings

Subject: Re: [boost] [units] gcc warnings
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-16 07:00:56

Emil Dotchevski wrote:
> On Tue, Jun 15, 2010 at 10:03 AM, Steven Watanabe
> <watanabesj_at_[hidden]> wrote:
> > Humph.  Has anyone in this discussion actually looked at the
> > code in question?
> > a) There can be no overflow because the possible values are
> > enumerated.
> > b) With the current code, the compiler will implicitly use
> > a static_cast.
>
> With the current code, the compiler will use an implicit conversion
> which is not the same as static_cast in general. Casts are designed to
> punch holes in the C/C++ type system, which by definition is a
> dangerous thing to do. In contrast, one has to assume that implicit
> conversions are a necessary, reasonably safe part of the language.

A static_cast in this context explicitly calls for the otherwise implicit conversion, with the intent of silencing the warning.  I think Steven was suggesting that the compiler was applying the same conversion(s) in either case.

> 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.

> 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, is the appropriate recourse to eliminate the warning.  Even so, assertions are a wise addition against future maintenance effects.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.