|
Boost : |
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-05-04 20:57:47
Jeff Garland wrote:
> > 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.
The way it's implemented in Wave is, that the library itself doesn't include
any serialization headers and the serialization code for the different
classes is disabled by default. If the user needs serialization support
(which is strictly optional), he/she needs to include the serialization
headers herself and to define the BOOST_WAVE_SERIALIZATION=1 to enable the
serialization code.
This ensures no serialization dependency is generated by default.
> >> 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.
In fact, it is disabled by default.
Regards Hartmut
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk