Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-04 20:11:55


Hartmut Kaiser wrote:
> Stefan,
>
>> Appologies from me, too, as now we are getting even further
>> from the original topic.
>>
>> I have seen at least one case where it was indeed X.hpp that
>> introduced the dependency to serialization code. However,
>> this generates another
>> problem:
>>
>> 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 this dependency.)
>>
>> 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.
>
> I'm not sure, if this is always possible.

This isn't a new debate, but I believe a separate user specified header is the
correct solution. This is how date-time is done and others should be as well.
  As I recall prior discussions, not all libraries have been factored that way
-- I think multi-index isn't -- Joaquin had some good reasons. Anyway, it's a
bit more effort, but because of the serialization design it should always be
possible do have external serialization functions. In general serialization
requires a pile of extra includes that should be avoided if possible.

>> PS: the library I'm thinking of is boost.wave, and there serialization
>> was dragged in whenever BOOST_WAVE_SERIALIZATION is defined.
>
> As far as Wave is concerned, the mentioned macro has no influence on the
> code generated for the library. You always can define
> BOOST_WAVE_SERIALIZATION to zero when compiling your code, even if the
> library was compiled with BOOST_WAVE_SERIALIZATION=1. The generated library
> has no dependency on Boost.Serialization.

Seems to me that unless it's essential to library function serialization
support should always be turned off by default.

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk