Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-25 11:48:44

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.


> 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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at