
Hi, I just ran into a nasty thing with Boost.Serialization. While restructuring some of our base libraries to get rid of unnecessary headers and reduce header dependencies in general, I suddenly got a hard-to-track-down #error in basic_archive.hpp saying that I need to include archive headers before other serialization headers. I remember a discussion on this list about this subject in the past. I quickly skimmed through the thread and can only make the same plea as others have made in that thread: Please, please, please get rid of this header order dependency. In larger projects such header order dependencies are incredibly hard to get right. I also don't see why I shouldn't be able to do the following: // A.hpp: #include <boost/serialization/access.hpp> #include <boost/serialization/nvp.hpp> class A { public: A(float value) : data(value) {} private: friend class boost::serialization::access; template <typename ArchiveT> void serialize(ArchiveT& archive, const unsigned int version) { archive << BOOST_SERIALIZATION_NVP(data); } private: float data; }; // UsingA.cpp: #include "A.hpp" // include first to make sure it includes whatever it needs #include <boost/archive/polymorphic_binary_oarchive.hpp> ... This technique is often used to make sure that headers can be translated "on their own", i.e. that they include everything they need. Another example that demonstrates how hard it can be to get the header order right: // B.hpp: #include <A.hpp> #include <boost/archive/polymorphic_oarchive.hpp> // ^-- BOOM! A.hpp includes non-archive serialization headers class B { public: void Save(boost::archive::polymorphic_oarchive& archive) const; private: A a; }; Of course I can swap the two includes, but why should I care that A.hpp includes serialization headers. Also note that this is a contrived example. It could be that not A.hpp is the culprit, but any other header included by A.hpp might include serialization headers. This makes it very hard to find the correct header order. Also, assuming A.hpp comes from another library that I have not written. Why should I know about its implementation details. Why should I have to care in what order I need to include headers from another library. So again, please, whatever the cause for introducing this header order dependency is, get rid of it. It wasn't there in Boost.Serialization 1.32.0 and it shouldn't be in 1.33.0 either. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at