Re: [Boost-users] multi_index uses serialization?

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-02-27 13:14:19

Hello Robert,

Robert Ramey ha escrito:

> 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.
> This seems to me awkward for those that want to minimize
> dependencies, compile times,
> etc.  It seems that it would also confuse things if one wanted to use a
> different serialization system other than the Boost one. When doing the
> serialization of std:: collections, I made headers of the form
> boost/serializaton/vector.hpp, etc. If course I couldn't mess with the
> headers std::vector.hpp, boost::shared_ptr, etc. But it seemed most
> natural to me as it only required code to be included that the programmer
> had made a deliberate decision to use.  Given this I sort
> of expected to see boost/multi-index:/serialization/hashed_index.hpp or
> maybe boost/serialization/multi-index/hashed_index.hpp.  These of course
> would include boost/multi-index/hashed_index.hpp etc as needed.
>
> I'm not campaigning for any change.  Its just that I thing my way of doing
> it is better.

Well, I thought about this kind of problems when designing the serialization
support of B.MI, and what you've got is the best I came up with. There is
a rationale for not having boost/multi_index/serialization/*_index.hpp headers,
let me explain: When you serialize a multi_index_container comprised
of N indices, every index gets involved in the serialization process; so, if
you have something like:

  tyepedef multi_index_container<
    element,
    indexed_by<
      ordered_unique<...>,
      hashed_non_unique<...>,
      sequenced<...>
    >
  > mic_t;

and want to serialize objects of type mic_t, you'd have (according to the
serialization header model) to include the following:

  #include <boost/multi_index/serialization.hpp>
  #include <boost/multi_index/serialization/ordered_index.hpp>
  #include <boost/multi_index/serialization/hashed_index.hpp>
  #include <boost/multi_index/serialization/sequenced_index.hpp>

Which looks like excessively cumbersome to me. Failing to include
one of the headers won't result in less-capable serialization support, only
in a compile-time error when trying to stream mic_t's.

A twist on this could be: why not embed all the serialization support
in one centralized header?

  #include <boost/multi_index/serialization.hpp>

This is convenient from the user's point of view, but doesn't scale up
well internally, cause adding a new type of index would cause this
header to grow regardless of whether the new type of index is used
or not. As things stand now, index types are entirely orthogonal
with each other in terms of code base, which is good.

So, my decision was to embed serialization support for each index
(and the multi_index_container wrapper itself) directly in their
corresponding headers, and I left the disabling macro just in case.
Faced with the dilemma of whether this support should be on or
off by default, I opted for "on" because, thanks to the autolinking
feature, when the serialization capabilities are not invoked the user
does not notice anything, perhaps some theoretical slowdown in
compile times.

> This seems related to a short discussion that occurred some time ago
> regarding the appeal of "convenience headers" which make sure
> that everything one might need is included under the short name.
> Some people hate 'em (e.g. me) and some people love 'em.
>
> I also think that as boost grows, the disadvantages of "including
> every thing that might be useful" will be more apparent.

Of course, if someone comes up with a friendlier approach to this
particular problem, I'd be happy to give it a try. Given the
situation I described above, I don't see how to provide a more
convenient header-based approach. Ideas?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo