On Sun, 25 Apr 2004 09:11:28 -0700, Robert Ramey wrote
Jeff Garland wrote:
Well, I think it belongs in the library supplying the data type not in serialization. Few reasons for this...
... good reasons listed
4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes.
Agreed.
FWIW - this gets my vote:
So for the particular case I posted I was planning on putting this code in boost/date_time/gregorian/greg_serialize.hpp
Time could would go into boost/date_time/posix_time/time_serialize.hpp
Considering the above, you might want to think about tweaking date time.
Sure, I might. Of course date is only one of several things I need to add serialization to.
By making a default constructor (that initializes as "not a date"),
Don't get me started on this ;-)
you could implement serialization as template member functions along the lines of the above. In this way adding serialization would:
a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used.
Are you saying there is actually extra runtime overhead with the way I've implemented serialization? If so, that needs to be in the docs b/c I was under the impression that external versus internal implementations would be the same... Jeff