Re: [Boost-users] [serialization]

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-13 13:59:51

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?

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

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

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

lol - well, you've got my vote.  it turns out that this is an artifact
of certain (all?) text streams.  So it doesn't appear in the binary
archives.  Perhaps this is why it hasn't come up more often.

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

they are - or least they are meant to be.  Any instance where they
are not should be reported as a bug.

Having said that, there are going to be some cases where they
ar not going to be portable.  Suppose the following:

a)  one serializes a variable of type size_t to a text archive.
b) value exceeds 32 significant bits.
c) the archive is shipped to another machine which has size_t
only 32 bits long.

As he archive is read by recieving machine.  An error should be
detected and an exception thrown when the value is read.

So although text archives are portable, one can still only reconstruct
C++ data which is in fact representable on the target machine.

I don't know if that decreases you 100% number - but its the best
we can hope for.

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

The question is how much effort should be directed working aournd
a library bug (if that's what it is) to a case which is so un-important
or trivial to address that even those people directly effected by it
are dis-inclined to invest any effort in it.  Its not that hard to fix
if someone really needs it.  So if it bothers you and you need
to fix it, test it, and send me your changes.

> 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)?

Archive class implementation throw documented exceptions in cases
where corrupted data is detected.  Serialization functions are totally
in hands of the user which implements them and can also throw
any of these exceptions - or its own if it prefers.

Robert Ramey