Re: [Boost-users] multi_index uses serialization?

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 #include #include #include 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 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