Re: [Boost-users] [serialization]

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-11-17 06:47:16

On 11/13/05 1:59 PM, "Robert Ramey" <ramey_at_[hidden]> wrote:

> Daryle Walker wrote:
>>>> * when booleans are output, booleans are converted to integers and
>>>> an assertion is thrown if the resulting value is other than zero or
>>>> one.
>> 
>> The compiler can only give 0 or 1, it cannot canonically give you
>> another result.
> 
> Hmmm - well its doing so in this case - canonically or not?

I was just talking about defined behavior, not the not-0-nor-1 case you got
from undefined behavior.  A footnote in the standard mentions that examining
a bool in an undefined manner may give neither-True-nor-False states.

>> As I said in another post, trying this on an
>> uninitialized "bool" has already given you undefined behavior, so you
>> don't know if you'll reach your assertion code, let alone trigger it.
>> (Also the 0 or 1 from the conversion doesn't tell you anything from
>> the internal representation.)
> 
> Hmmm - suppose I implement the following code:
> 
> bool tf;
> int i = tf;
> assert(0 == i || 1 == i);
> 
> and the assertion is invoked.  Is it not correct to conclude that there is
> a problem with the code and that it should be somehow altered?
> Of course a smart compiler will catch this sooner.  In other cases
> a smart runtime system/machine might throw a data exception the
> instance that i=tf is executed.  Great -  We've trapped a bug in user
> code.  But suppose that doesn't happen and the exception is invoked.
> Well, great again - for the same reason.  Suppose that  the
> assertion isn't invoked (may the compler "helps us out" by initializing
> tf.  So we're stuck with a bug - same as before.  So the assert
> might not be necessary, it might detect a bug not otherwise detected.
> The fact it might not on some platforms doesn't mean that it shouldn't
> be included.

How is the user supposed to know if they're on an environment with your
"aid" or one where the aid doesn't work?  Are you going to make (and
maintain) a list?

>>> Some kinds of programming errors aren't worth trying to detect.
>>> Passing uninitialized data is fundamental brokenness, and looking for
>>> it with only in bools is rather silly.
>> 
>> I agree, especially since I think that such detection isn't possible.
> 
> same old question - what's the downside with detecting fundamental
> brokeness - sounds like a good feature to me !!!
[TRUNCATE]

Not if it doesn't work reliably and/or gives the user false hopes.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com