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

From: Austin Bingham (austin.bingham_at_[hidden])
Date: 2005-01-06 10:54:59

> I'm not convinced this would work very well.  when loading a data value, you
> have to know ahead of time what type its going to be - float or string.

As I understand things, istream::peek() is always going to work,
meaning that you could check to see if the next char is, for example,
an 'n'. If so, this would indicate that nan was written; otherwise, a
normal float could be read. At least in the toy code I've written,
this works.

This approach (assuming it works completely) has the benefit of not
requiring extra information pertaining to the nan-ness of the value.
It has the downside, as you point out, of taking some extra cycles.
I'll address this in bit.
 
> 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.

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

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

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.

Austin Bingham