Re: [Boost-users] boost::serialisation - portable_binary_oarchivenotpart of library
Hello Robert, I think a 'finished' protable_binary_oarchive/ protable_binary_iarchive would be very useful for network applications (passing message structures -> header, body, trailer). I'm not familiar with boost::serialization (my first look into it) - I see some specializations of load for integral types an a templated member function for all others. Serialisation for std::strings and chars are supported in a portable manner? Only floating point types have to be implemented for portability? Oliver
I made it as an example on how to extend the library by deriving from an existing archive. To "finish" it would require implementing serialization of floating point types in a portable manner and this turns out to be a non-trivial task. Implementing this would be too much work and would sort of compromise illustrative value of the example.
Oliver.Kowalke@infineon.com wrote:
Hello Robert,
Serialisation for std::strings and chars are supported in a portable manner?
This starts to raise the issue of what it means for a binary archive to be portable. Suppose an archive is created on an ascii machine and read on an ebcdic machine. Or more commonly, an archive is created in an environment is such that the default multi-character encode is latin characters and read my a machine whose multi-character encoding is Japanese characters. Should characters be translated. The native binary archive assumes no portabilty requirement and that the only requirement is maximum speed. A portable binary archive has to start making lots of decisions and trade offs. What is fast/universal format for floats/doubles/etc, how to handle things like invalid floats, nans, +/- inf, +/- 0, etc. What about endienness? the portable binary archive include creates a specific endienness. This will be a performance issue for machines that don't match the endiennes chosen. So someone will say they want o choose the endieness with some sort of switch or perhaps create the archive with the native endieness of the creating archive and make an adjustment on the fly if the recieving machine doesn't match. Oh and some have suggested that a common format such as XDR be used. As it typical, something starts out seeming simple, but by the time you get to the point of trying to "sell" it to the boost community it morphs into something pretty much impossible to implement and still get a concensus for acceptance. So, I've left these issues for someone who has a need for such a thing. As I said, it seems no one has had such a need to actually do any work - so there it stands. Good Luck Robert Ramey
Only floating point types have to be implemented for portability?
Oliver
I made it as an example on how to extend the library by deriving from an existing archive. To "finish" it would require implementing serialization of floating point types in a portable manner and this turns out to be a non-trivial task. Implementing this would be too much work and would sort of compromise illustrative value of the example.
Hi, I am kind of confused about the documentation on this topic. What do I need to override? Or do I need to explicitly specified a default constructor with no argument in each one of the class? --------------------------------- Bring words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail.
"sui tam"
participants (3)
-
Oliver.Kowalke＠infineon.com -
Robert Ramey -
sui tam