$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: martin.ecker_at_[hidden]
Date: 2005-08-29 07:33:50
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_at_[hidden]
http://www.tab.at