Robert Ramey <ramey <at> rrsd.com> writes:
Basically, I see this as a very positive thing and want to do everything I can to support your efforts. Your code supports save and load for two new formats (XDR and CDR). This is a valuable contribution. I'm also pleased that the serialization library has been deemed (at least by one person) to be worthy of investment of such an effort ( 1500 lines of code !).
Actually, XDR and CDR are of secondary interest for me; I'm interested in being able to save to proprietary formats (which often means that the applications involved never got around to specifying a standard format...). There must be thousands of ad-hoc binary formats in use today.
1) I wonder why you derived ordered_oarchive from basic_binary_oprimitive<Archive, OStream> . It doesn't seem that any of the functionality basic_binary_oprimitive actually used. I presume the same goes for ordered_iarchive .
I'm using the save_binary / load_binary functions from basic_binary_oprimitive and basic_binary_iprimitive.
2) there's some stuff in boost that addresses alignment in a guaranteed? Portable manner that may relevant here. Sse #include <boost/aligned_storage.hpp> . BTW - the best way to make your code portable without cluttering up with #ifdef etc... is to use more boost stuff - let other people clutter up their code with #ifdef all over the place.
Yes, but the aligned_storage template helps with platform-specific alignment within the machine. I don't see how it helps with platform-independent alignment within the content of the archive...
3) I'm curious about the override for the saving of vector. It seems to me equivalent to the one included with the system. And if vector requires special treatment, what about the list, et al. This doesn't seem necessary to me. Perhaps the fact that I did treat strings specially was misleading. I considered this a special case. I don't think vectors are in this context.
I need to override the serialization of vector, because the vector must be serialized with a known policy to yield a required layout in the archive. The fact that this serialization happens (at this point in time) to be exactly the same as the default implementation is not relevant - that can be changed at any time, but the CDR, XDR and other binary formats must not change. [ Points 4-6 conceded ]
7) I'm just a little queasy about using the term marshalling. In fact any of the archive implementations could be used for marshalling - not just a binary one (XML is the favorite flavor of the month). So I think it's sort of misleading. I think it is very helpful that your naming scheme xdr_oarchive, cdr_oarchive, leverages on the existing one.
Yes, I see what you're saying. I'll have a think about this - but the term 'marshalling' is not particularly prevalent in the code. Even if the term does have broad application, I think I am using it in the traditional sense.
8) in my native binary archive, I used a template parameter for the stream class. As it stands, I don't test or use the corresponding archive for wide character streams because the WEOF would need special treatment. I haven't spent any time on this. Perhaps you've addressed this in some way.
No, I was hoping you'd have it all sorted out - I've never used a stream specialised with anything but char. In fact, it doesn't really make sense to me, to produce binary output as anything but a byte stream - I was just following your lead, really :)
I didn't look in that much detail. I suspect that's enough to keep you motivated. Good luck and thanks for working on and with the library.
Yes, thanks for your comments. Working with the library is a pleasure. Matt