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