Boost logo

Boost Users :

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-02-27 00:45:53


Robert Ramey wrote:
> I never realized this before. Truth is I never really looked at multi-index
> because I haven't needed it yet. But this post raises some questions in my
> mind.
>
> This means that the default is that any usage of multi-index includes
> serialization library headers regardless of whether boost serialization
> is to be used.

I agree this isn't optimal. I also don't think it's consistent with what
other libraries do -- well at least date-time. So, date-time has added a
'convenience header' in 1.34 (boost/date_time.hpp) which includes all the
types and the i/o, but not the serialization interfaces. You still have to
specially include other headers to get the serialization functions. I'm not
suggesting that this is the 'one right way', but I think it's a reasonable way.

>...snip...
>
>
> "JOAQUIN LOPEZ MU?Z" wrote:
>
>> Furthermore, if for whatever reason you don't even
>> want for Boost.MultiIndex to include any
>> Boost.Serialization-related header (for instance,
>> if you're using a partial copy of the Boost distro
>> without the serialization stuff), this can be done
>> by defining the macro
>>
>> BOOST_MULTI_INDEX_DISABLE_SERIALIZATION
>>
>> either globally (in your project settings or compiler
>> commandline) or in each relevant .cpp prior to the
>> inclusion of Boost.MultiIndex headers.

At a minimum this seems backwards in that I'll bet most MI users don't use
serialization. I also don't really care for the macro approach -- probably
because I have to clutter my code to turn something off. I'd usually expect
to 'add something' to my code to enable another feature. Bust, I guess you
could argue it either way. In any case it would be nice to be consistent
across boost libs on this. What do the other libs that support serialization
do -- what are they, graph, ?

Jeff


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net