Boost logo

Boost Users :

From: Nigel Rantor (wiggly_at_[hidden])
Date: 2005-11-09 21:37:38


Robert Ramey wrote:
> Paul Giaccone wrote:
>
>>For booleans, though, a value of other than 0 or 1 means it has not
>>been initialised, and perhaps this should throw an exception on
>>writing to the archive rather than on reading from it.
>
>
> Hmmm, I'm not sure about this. Do we know for a fact that a bool variable
> will always contain 1 or 0? I've never seen code trap on an un-initialized
> bool. It seems that even an uninitialized bool corresponds to true or
> false.

No, bools won't always contain 1 or 0, like other types their value is
be undefined if they have not been initialised, depending upon where
they have been declared.

<caveat>
C++ isn't my day job...I just use it for fun things...
</caveat>

When bools are used in logical operations they are converted to
integers, so depending on what your bool happens to contain before
initialisation it could evaluate to either true or false.

> Perhaps part of the problem is that I used 0 and 1 for bool variable
> in order to not included english strings "true" and "false" in text files
> and to save space.
>
> I'll think about this.

My two proposals would be the one that encourages pragmatism and the
other that encourages correctness.

Pragmatic:

Well, how about simply treating anything other than 1 as false? I
realise this means that you are implicitly initialising someone elses
variable should they serialise and then deserialise but it would seem to
preserve the effect that you would witness should you use such a
variable without performing that set of operations anyway so it would be
an "invisible" side-effect.

Correct:

Initialise all your variables. Shoot all programmers who don't!

And of course, the one true way - tell everyone to initialise their
variables or bad things might happen and then be lenient on parsing anyway.

Regards,

   n


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net