Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
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. 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. By making a default constructor (that initializes as "not a date"), 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. Robert Ramey
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
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote:
By making a default constructor (that initializes as "not a date"),
Don't get me started on this ;-)
The default constructor can be private. Objects constructed this way will be always filled with previously serialized data - no 'empty date' will ever exist. /Pavel
On Sun, 25 Apr 2004 19:41:52 +0200, Pavel Vozenilek wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote:
By making a default constructor (that initializes as "not a date"),
Don't get me started on this ;-)
The default constructor can be private. Objects constructed this way will be always filled with previously serialized data - no 'empty date' will ever exist.
Good point. I'm going to relent and make a date have public constructor anyway, since users have been asking me to do it. But there are other things in date_time, like the date_generators, that I will be implementing serialization for and they have no reasonable default constructor. Jeff
participants (3)
-
Jeff Garland -
Pavel Vozenilek -
Robert Ramey