Re: [Boost-users] [serialization]

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-11 16:18:18

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

> Ian McCulloch wrote:
>> Robert Ramey wrote:
>
> Your reference below - http://lists.boost.org/boost-users/2005/01/9359.php -
> touches upon this subject in an interesting way. "This [NaN problem] seems
> to be a result  of relying on the, AFAIK, undefined behavior of writing 
> NaN/infinity
> to a stream; it will work correctly with some standard library 
> implementations,
> but not all."  I don't know what the standard says about writing/reading
> a NaN or +/-inf to a stream and reading it back.  

I recommend getting a copy of the C and C++ standards.  It's cheap,
easy, and well worth the investment.  When using the default standard
"C" locale, floating point numbers are converted according to
corresponding stdio functions in the C standard.  The C standard
describes how NaNs are converted in 17.9.6.1 and 17.9.6.2.  It
specifies that NaNs are read back in the same way they're written out.

> Also what do most i/o stream implementations do?  Certainly, the
> users that have had the problem aren't using stream libraries which
> support this behavior.  Then the question arises, if it isn't
> important enough for the common stream library implementations to
> support it, why should we invest effort in it.  

Because it's important for your users.

> I would guess that the the reason the problem has come up so
> infrequently is that users don't need to save/load these types of
> values very often or its easy to work around.  Otheriwise the
> standard stream library would have addressed this stuff long ago -
> and of course we wouldn't be discussing the issue now.

We're discussing it now because you announced a plan to assert when
passed a NaN.

>> Not to mention fast array serialization, for which Matthias Troyer
>> has, to my mind, presented convincing arguments that it should be
>> part of the core functionality.
>
> He's wrong about this.  There is no advantage to including it in the
> place he wants to.  

You keep on asserting that, but when he explained the advantage, you
didn't reply.

> Everything he want's to achieve can be obtained without mucking
> about in the library itself which is already large and complex
> enough.

Matthias isn't wrong.  For what it's worth, if I were in your shoes
I'd be thinking *very* carefully before making that assertion so
baldly, because the chances of being right are so slim.  My experience
of Matthias is that he's smarter than the rest of us put together.

> The final result would be less tightly coupled, more reliable,
> optional for users who don't need it, more easily testable and
> demonstrably correct.
>
>>>> 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.
>>>
>>
>> I have heard mumblings to that effect.
>>
>>> Hmm - I can't imagine why anyone would want to do that.
>>
>> and THAT, I think, is the crux of the problem.
>
> OK, let me rephrase that.  There would be no advantage to doing that
> since one could ->
>
>>> make thier own derivation(s) of one or more archive
>>> classes or even a whole new archive class - but that doesn't
>>> represent any conflict with the current library.

A special archive class doesn't help if the interface for serializing
arrays isn't a standard part of the archive concept.  Everyone who
writes a datatype containing an array will need to use that interface
in his serialize function.

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