Re: [boost] Re: Serialization Formal Review #2

Thorsten Ottosen wrote:
class gps_position { public: int degrees; int minutes; float seconds; gps_position(){}; gps_position(int d, int m, float s) : degrees(d), minutes(m), seconds(s) {} };
I think it should be stated that this is not recommended practice, ie, this class has a non-trivial invariant and should not have public members.
I might add a friend rather than use public. But this small code snipet is used to illustrate the non-intrusive serialization - nothing more. BTW the actual demo programs don't use this. What is the non-trivial invariant here?
A better example might be to use std::pair.
The examples use pointers in arrays and pointers in standard containers. I think the text shouldstate that this is not recommended; or even better, throw in a shared_ptr instead. The code in the example is inherently exception unsafe.
Therefore I also think that container< shared_ptr<T> > should be supported by default whereas container< T* > is, well, ok if you don't have exceptions somehow.
Writing a good tutorial is much harder than it looks. My main motivation was to introduce one concept at a time. The basic building blocks of serialization are serialization of primitives, pointers and classes - both intrusive and non-intrusive. All the rest is the result of composition of these basic operations. My tutorial reflects this. That's why serialization implementations of standard library components such as pair, vector, etc are described at the end rather than at the beginning - they are not primitive operations. Anyway, I'll consider adding some comments to remind the reader of the intended purpose of he tutorial example. Robert Ramey

Thorsten Ottosen wrote:
class gps_position { public: int degrees; int minutes; float seconds; gps_position(){}; gps_position(int d, int m, float s) : degrees(d), minutes(m), seconds(s) {} };
I think it should be stated that this is not recommended practice, ie, this class has a non-trivial invariant and should not have public members.
I might add a friend rather than use public. But this small code snipet is used to illustrate the non-intrusive serialization - nothing more. BTW
"Robert Ramey" <ramey@rrsd.com> wrote in message news:20040414170207.5A5BB3150A@acme.west.net... the
actual demo programs don't use this. What is the non-trivial invariant here?
I assume that not all data members can have arbitrary values. How many seconds to a minute before the seconds should be reset etc.
Anyway, I'll consider adding some comments to remind the reader of the intended purpose of he tutorial example.
Thanks. br Thorsten

Hi Robert, I have two more questions regarding the serialization library which I need to have answered before I can see if I can read my old archives with your library: 1. when overloading the save/load functions in an archive, do I bypass writing preambles and other class information or do I need to overload operator <<? What is the difference between implementing operator<< and save? 2. which functions do I need to implement in my archive class to skip writing the standard preamble that your archives write? Is it just the init function or are there more functions? Best regards Matthias
participants (3)
-
Matthias Troyer
-
Robert Ramey
-
Thorsten Ottosen