Re: [Boost-users] [serialization]

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-10 16:53:20

"Robert Ramey" <ramey_at_[hidden]> writes:

> Nigel Rantor wrote:
>
>> If Robert can find a nice way of trapping uninitialised variables (not
>> simply bools of course) and throw exceptions for these then that's
>> great. I'm not sure that is entirely possible though. (and I haven't
>> psent any time thinking about it either)
>>
>
> I checked my reference on the subject of bool/int conversion. This is
> Section 4.2 Booleans in "The C++ Programming Language by Stroustrup.
>
> I see that "in arithmetic or logical expressions, bools are converted to 
> ints...
> if the result is converted back to bool, a 0 is converted to false and a
> non-zero value is converted to true".
>
> Looking at the above

Do not look at the above.  It contradicts the standard, as shown:

  5.14 Logical AND operator 5 Expressions

  1 The && operator groups left-to-right. The operands are both
  implicitly converted to type bool (clause 4)...

You don't think compiler implementors refer to TC++PL when deciding
how to write their compilers, do you?

>  and having considered the postings on the thread
> my inclination is to do the following:
>
> * when booleans are output, booleans are converted to integers and
> an assertion is thrown if the resulting value is other than zero or one.

What do you mean, "an assertion is thrown?"  Only exceptions can be
thrown.

> This is in line with my view of trapping a program as soon as possible
> when any kind of programmign error has been detected.

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.

> This naturally suggests the following for floats and doubles.
>
> * any attempt to save floats or doubles for which the result of isnan(..) is 
> false
> will trap with an assertion.

So, you're going to assert whenever someone tries to save a non-NaN?
That sounds pretty useless.  Even if you meant the opposite, it would
be an unfortunate choice.  Non-signalling NaNs should be serializable.

> This would be a good thing from my standpoint as up until now a NaN
> could be saved but not recovered as the standard text stream input
> chokes on the Nan Text.  

Seems like you should work around that problem.

> Meanwhile the binary input just loads the bits whatever they were.
> This conclicts with my goal of making all archives behave alike.

Good, then I'll (foolishly) assume you'll make NaNs serializable
everywhere...

> I'm concerned that someone standup and show "But NaN is a valid value
> for a float or double and I should be able to serialize that!!!".  

Damn straight.

> I'm inclined to reject this characterisation basically because doing
> so will make my life easier.  This will trap some user's errors at
> the cost of prohibiting some behavior that could be defended as
> correct.

I find it very distressing that you keep dismissing the needs of the
numerics community.  This is likely to lead to something very
distasteful, like a semi-official branch of the serialization library
that works the way we need it to.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com