[Boost-users] Re: Re: Serialization with NaN and infinity

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-01-06 12:39:06

Austin Bingham wrote:
>
>> b)define a special type for Nan:
>> c) a simpler approximation of the above could easily be made.
>  ...
> The problems I have with these approaches deal, essentially, with the
> cognitive load on the programmer. Now a serialization lib user has to
> remember to use the wrappers if dealing with NaN, or face the wrath of
> a compiler that is not going to tell you what broke when you try to
> read a NaN. Maybe this is not as big a deal as I suppose, but I can
> envision scenarios where this would be a problem.

The problem is that someone is going to say "I don't need this and I don't
want to slow down my application" or something like that.  My method permits
one to choose weather or not Nan is going to get special attention on an
item by item basis.

>
> These approaches (although I haven't seen the variant serialization
> solution) would incur extra storage for each float/double.

The variant serialization is mentioned as an incentive to get someone
interested in implementing this.  This wouldn't be that hard, but could be a
little bit subject to contraversy depending on the implementation.

Not that the serialization wrapper I proposed could be implemented
differently for native binary files - which don't need anything special.
This would give each platform what it needs.

>
> So, taking all of your comments into account (I hope), I have another
> idea. Would it be possible to make the text-primitive functionality of
> xml and text archives a programmer modifiable property?

This is pretty much what the wrapper functionality above does.
>The most obvious approach, I think, would be to give the archive_impls a
> template parameter of TextPrimitive. Rather than having a hard-coded
> inheritance from basic_text_i/oprimitive, this TextPrimitive would be
> the base class. By default, of course, the basic_text_primitives would
> be used, but alternatives could be supplied by anyone.

On the other hand, one could modify the code so the default is to flag Nan
on text primitives and require usage of the wrapper to override it.

> This has, I think, the great benefit of keeping the primitive
> representation and overall file structure orthogonal. Again, I'm
> waving my hands a lot here, but I don't see any reasons in the code
> why this couldn't be done, but neither do I have intimate knowledge of
> the code.

Well, everything is doable, the problem is coming to agreement on what to
do.

Actually, my main reluctance is really just inertia.  If I had thought about
this point long ago, I probably would have included it the text primitives.
If one is using a text archive, the extra overhead of using a Nan flag is
not going to be noticiable.  If efficiency at this level is a concern, one
is going to be using a native binary archive anyway.  Adding in this in to
the text primitives would require that I go investigate Nan and what it
means in different environments (e.g. IEEE 80 bit ) and to what extent there
are portable functions for checking whether or not a float, double, (complex
?) is a Nan.  I'm also a little concerned at this point of invalidating
portable text archives created by previous versions.  So its really is just
inertia. (I'm also bogged down in other stuff now)

Robert Ramey