From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-05-04 13:58:58
Peter Dimov wrote:
> Sorry for not following the thread properly, just a quick note:
>>>> (e.g. serialization support for core libraries should be supplied by
>>>> serialization and not core [as I believe it is now, at least in many
> This is not right. Serialization support for class X should be provided by
> X.hpp and it must be possible to do this without depending on any other
Appologies from me, too, as now we are getting even further from the original
I have seen at least one case where it was indeed X.hpp that introduced
the dependency to serialization code. However, this generates another
If X is usable without serialization, users shouldn't be forced to also
link to the serialization library, just because of this dependency.
(In the particular case I have in mind this dependency was controlled
by a preprocessor macro. That's not very practical, since packagers
surely won't provide two sets of packages for X, one with and one without
Thus, I'd suggest to encapsulate the X-serialization functionality into
a separate library (may be header-only), such as X_serialization.hpp
etc. Then I can still use X stand-alone, and drag in the rest whenever
I need it.
PS: the library I'm thinking of is boost.wave, and there serialization
was dragged in whenever BOOST_WAVE_SERIALIZATION is defined.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk