Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-05-05 13:04:41

----- Mensaje original -----
De: Jeff Garland <jeff_at_[hidden]>
Fecha: Sábado, Mayo 5, 2007 5:14 pm
Asunto: Re: [boost] Serialization support, Was: [BoostCon07][testing]
        Session reminder.
Para: boost_at_[hidden]

> > So, I had no other choice but to implement serialization
> > support for Boost.MultiIndex in an interface intrusive way.
> Thx for explaining this. I'd like to go back the the header
> inclusion dependency issue. The need for internal access
> isn't a reason why the serialization headers need to be
> 'included by default'. A friend class/function in separate
> serialization header could implement the serialization using
> the internal mechanisms that are otherwise an implementation
> detail.

Hello Jeff,

Yep, the need for intrusive serialization support does not
preclude its relocation to separate serialization headers. In
the discussion we had two months ago I gave my rationales for
not using separate headers, let me quote that for the readers'

Well, I thought about this kind of problems when designing the
support of B.MI, and what you've got is the best I came up with. There
a rationale for not having boost/multi_index/serialization/*_index.hpp
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<
> mic_t;

and want to serialize objects of type mic_t, you'd have (according to
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,
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.

What's your stance on this? If there's some agreement that
the actual approach should be changed I can of course do
it --it'd only raise small backwards-compatibility glitches.

BTW, if the separate header is agreed on as the preferred
mechanism for bringing in serialization capabilities, I think
it'd be great to reach a consensus on the names of those
convenience headers; there are various options:

  1. boost/lib/T_serialization.hpp
  2. boost/lib/T_serialize.hpp (date_time approach)
  3. boost/lib/serialization/T.hpp (consistent with B.S approach)

I like 3 best because _serialization or _serialize suffixes
tend to give long file names, and we've got the 31 char limit
rule still in effect.

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at