Re: [boost] Serialization support

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-05 14:46:02

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

Thx...seemed like it was longer ;-)

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

I agree, but it could be explained for the header minimalists in a couple 
paragraphs.

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

Here's where I disagree with your decision.  I think the 'scale-up' is a 
non-issue.  Most of the time the extra headers won't matter, so the combined 
header is the easy way for users.  But really, you could easily offer both 
options if you wanted.

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

Here's another use case. Of I try to subset Boost with multi-index only I need 
to know about the macro or carry along the serialization headers, and whatever 
it includes, unless I know about the macro.  I'd like to have a smarter 
version of bcp where I can say something like:

   bcp --no-serialization lib1 lib2

and it would make me a subset that ignored the serialization dependency.

> 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)

Fair enough, but I guess I don't like number 3 much as it interferes with 
other subdirectory structure that the library might have.  So I'd have to have 
boost/date_time/gregorian/serialization/ -- I guess I could live with it as 
long as I could have a date_time/serializ(e)(tion).hpp that wrapped up all of 
the library. It would sure make that bcp thing easy.

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

True, but don't we have a 512 char path too ;-)  Anyway, I'd be willing to 
switch if people prefer 1 or 3.

Overall, I think Boost is big enough and mature enough that we should settle 
some of these things for the goal of overall Boost usability.  Even things 
like the lack of an 'all in one' header throws users off track....which is a 
shame.

Jeff