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. 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. Robert Ramey "JOAQUIN LOPEZ MU?Z" wrote:
Furthermore, if for whatever reason you don't even want for Boost.MultiIndex to include any Boost.Serialization-related header (for instance, if you're using a partial copy of the Boost distro without the serialization stuff), this can be done by defining the macro
BOOST_MULTI_INDEX_DISABLE_SERIALIZATION
either globally (in your project settings or compiler commandline) or in each relevant .cpp prior to the inclusion of Boost.MultiIndex headers.