----- Mensaje original ----- De: Jeff Garland <jeff@crystalclearsoftware.com> Fecha: Sábado, Mayo 5, 2007 5:14 pm Asunto: Re: [boost] Serialization support, Was: [BoostCon07][testing] Session reminder. Para: boost@lists.boost.org
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