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