From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-25 11:11:28
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