
I've just taken a short look at this implementation and it looks pretty good to me. I like the usage of BOOST_STATIC_ASSERT along with code comments that start with "If your compile fails here .... I also like the extensive comments/rationale right there in the code. a couple of minor nits. a) I would like to see the code formated slightly differently to make it more readable. Specifically I would like to see #if indented in the same way that the normal if( is. I realise that this is my particular taste so I don't want to make a huge argument for it. But aesthetically it would better match the other serialization code. Also consistent usage of 4 space indents for tabbing would be nice. b) The version of the portable binary library that is currently part of the package uses the endianness on the machine which create the archive. On reading the archive, the endienness is swapped around if and only if the the endienness of the reading machine is different than that contained in the archive. The endiennes of the archive is stored in the archive header. The idea is that the most likely reader of an archive is one using the same endienness of the creator. Also, Endienness of the archive being created can be overridden during archive construction. This is basically a way of keeping myself out of any endieness debate. c) I would like to see the complete test suite run on this. If you checkout the libs/serialization/test directory. You can see that there is a *.hpp file for each archvie type. By adding your own eos_portable_binary_archive.hpp and using a command line switch the the bjam invocation, you can run all the serialization tests on just your new archive. From personal experience I can tell you that this is an eye opening experience. d) it seems that its portability is not universal which is OK by me as it seems to have a pretty wide coverage. But more information on this would be useful. e) Note that the current text archives don't support serialization of NaN of various types. They just throw exceptions. So I have no problems with you're doing the same thing. However, not everyone agrees with me on this so expect some complaint. The issue of portably serializings NaN, should be addresses in all portable archives as a group - as it is essentially the same problem. Oh - then there is a documentation page. Good Luck with this. Robert Ramey Pfligersdorffer, Christian wrote:
Dear boost fellows,
during the last two weeks I finally had time to port our archives to recent boost versions up to 1.36. I also refactored a bit, put the archives into namespace eos and renamed them portable_[io]archive in order to prevent further mix-up with the portable binary archive from the examples.
In addition I finally did some testing on x64 and found our code working without complaints. So I encourage anyone who wants to use binary serialization across different platforms with floating point support to have a look at it at the boost vault:
http://www.boostpro.com/vault/index.php?directory=serialization
Cheers,