Vladimir Prus wrote: Robert Ramey wrote:
Header file order dependencies, from an end-user's perspective, are a minefield it is best to avoid at all costs.
Well, that would be my preference, but in some cases its unavoidable. In the serialization library I've got a couple of situations:
export.hpp:
the function of BOOST_CLASS_EXPORT("classname") is to instantiate
code for the particular class for all archives used. The list of all archives used is built from looking at the guard macros from previously seen *archive.hpp files. This permits instantiations to be limited to those *archive classes actually used whose declarations have actually been included. That alternative to this would be to instanciate code for all archives - which would make programs much bigger and take much longer to compile.
I recall that I did suggested one approach. BOOST_CLASS_EXPORT can register the class with all previously included archives and, unconditionally, with polymorphic archive. During saving, you can check if the saved class is registered with specific archive type. If not, you wrap archive in polymorphic archive and save. That would be slower, but in most situation extra virtual function call won't be a practical problem.
In the rare case where it will be a problem, user can: 1. Include necessary archive headers 2. Invoke BOOST_CLASS_EXPORT *again* in his module, after including another archive header. If BOOST_CLASS_EXPORT tolerates multiple invocations, this will instantiate the code for the needed archive type, and make saving to that archive type go without polymorphic arhive.
export.hpp is already quite complicated. This would seem to add a huge amount of effort at compiler and at rntime. It would also add dead code to almos t every executable using the library. It would seem a huge price to pay just to permit one to say. #include <boost/serialization/export.hpp #include <boost/archive/text_iarchive.hpp> rather than #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/export.hpp
I never understood this. BTW, did you have a chance to try my ADL patch?
I considered your patch, tested it on my own system, and rolled into the main CVS sometime ago.
"all <boost/archive/...> should be listed before all the <boost/serialization/...> includes"
Its very easy to remember and is enforced by and #error ... if the rule is violated. It does inhibit the mixing of <boost/archve/..> and <boost/serialization/..> includes other header modules. But in view this should never be done anyway as doing so compromises the orthogonality of the <boost/serialization/..> and <boost/archive/..> headers which is a key concept of the library implementation.
I'm sitting here hoping against hope that this will not turn into another very long thread.
Sorry, it might turn into a long thread after all, because you haven't still answered the attached message of mine. To summarize, I claim that the rule immediately prevents the "include my own headers right at the top" practice that I use.
Here is a copy of your preveious post - I'll answer it here
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just:
#include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp>
I don't understand you. If A.hpp contains the above, and my .cpp files contains
#include "A.hpp"
#include <boost/archive/text_oarchive.hpp>
I would recommend taht the above be changed to: #include <boost/archive/text_oarchive.hpp> #include "A.hpp"
Please take a look at:
I looked at your examples, made some changes in the library, tested them an checked them in.
The second example is typical and very easily resolved. Just move the *archive includes above static.h (which indirectly include the serializations of for a class Module data.
As I did explain, I want "static_data.h" (just like every header corresponding to my .cpp) to be the very first include in my .cpp file.
Did you see my arguments? Do you find them weak? If so, can you explain why?
Your requirement that static_data.h be first in every header conflicts with my requirement that serialization headers be after archive headers. I've explained why, given the alternatives I have available, I think its the best one. That's the best I can do. Robert Ramey