Re: [boost] [units] gcc warnings

Subject: Re: [boost] [units] gcc warnings
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-06-17 20:53:00

On Thu, Jun 17, 2010 at 4:44 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> On Wed, Jun 16, 2010 at 10:16 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>>
>> > I don't see how static_cast would be able to hide an error.
>>
>> The general point is that casts do more than simply silence
>> warnings. Example:
>>
>> void foo( short x );
>> int value();
>> ....
>> foo(static_cast<short>(value())); //static_cast used to
>>                                   //suppress a warning
>>
>> Later under maintenance we introduce an additional foo overload:
>>
>> void foo( long x );
>>
>> Now the call to foo with the static_cast<short> will continue to
>> compile while without the static_cast you'd get a compile error.
>
> That makes sense.  However, in order for that code to be useful
> after the maintenance change, the result of calling value() would
> need to be cast to either short or long to avoid the ambiguity and
> casting to short could be justifiable.

The reason why this situation is an error is that none of the two
possibilities is better than the other. In this case, one could use
static_cast (after seeing the error!) to choose, but in my experience
the bug such compiler errors unveil is that a third, int overload is
erroneously missing.

The problem is that static_cast doesn't only prevent warnings. A
correct approach to preventing warnings should only prevent warnings.
It certainly shouldn't be messing with the type system of a language
built around type safety.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode