Re: [boost] Serialization support, Was: [BoostCon07][testing] Session reminder.

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]

> JOAQUIN LOPEZ MU?Z wrote:
> 
> > 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'
convenience:

<quote>
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. 
</quote>

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