Re: [Boost-users] [serialization]

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-11-13 07:55:02

[I was going to write a similar response, but decided to crib off this one
instead.  (So I generally agree with Mr. Abrahams.)]

On 11/10/05 4:53 PM, "David Abrahams" <dave_at_[hidden]> wrote:

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

And the conditions in the quote are ambiguous.  There's really arithmetic,
shift, relational, bit-wise, and logical categories to consider.  For all
operators but logical, any "bool" argument gets promoted to "int."  For the
logical operators, any non-Boolean argument gets converted to "bool."  As
far as the result is concerned, the relational and logical operators
DIRECTLY return a "bool," it isn't "converted back."  (The result of the
other operators match whatever the [first] argument(s) is, after any
promotions.)

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

The compiler can only give 0 or 1, it cannot canonically give you another
result.  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.)

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

I agree, especially since I think that such detection isn't possible.

>> This naturally suggests the following for floats and doubles.

Nothing natural about the following, since the logic was flawed.

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

A not-a-number value is not the same as an uninitialized one.  From the
perspective of the C++ object model, a built-in floating-point variable
having a not-a-number state is still considered initialized.  (There may be
bit patterns that don't match any valid state for a float, not even NaN.)

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

Another post in this thread mentioned another thread from a year ago.  That
thread said that some environments do provide I/O that can save and load NaN
(and infinite) values to/from text.  Mr. Ramey was concerned with the
environments that couldn't.  At this point, I'll propose not worrying about
such environments, even if they're popular.  You can't give tremendous
effort to support all the brokenness out there (and I hope that we don't
expect you to).  Sometimes you have to tell the user that they're out of
luck with that particular configuration.

And, AFAIK, not even text archives are 100% portable between environments,
are they?

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

When I said that sometimes you have to give up, I only mean in terms of
environments too broken to give you the help you need.  You shouldn't
(permanently) drop features just to make your "life easier" if they're the
right thing to do.

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

Also, this route needs (yet another) special case and more code, and I think
we should minimize that.  (And remember that not all floats are IEEE, or
even have NaNs!)  Anyway, do we provide a way for a (user-created)
serialization routine to bail if the archive gives bad values (like it's
corrupt or from another platform)?

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