Robert Ramey wrote:
Vladimir Prus wrote:
Robert Ramey wrote:
Richard Jennings wrote:
I have found that the requirement that no serialization headers can be included before any archive headers means that you have to be careful which serialization headers you include in your class headers and indeed in what order you include them.
It is my intention that this issue be addressed with the simple rule:
"all headers from the serialization directory should follow and headers from the archive directory"
I believe that this rule should be very easy to follow.
You keep on making this statement, which is simply false.
The statement "I believe that this rule should be very easy to follow" is definately true. I'm quite sure I know what I believe.
Oh ;-) I kinda though that "I believe" is just a polite way of making a statement.
We've discussed this with you on the boost ml, and in the end result you've told that I should drop my design practice of including my headers first in implementation files, before any system and boost headers.
That's basically a global change in style, and not so "easy to follow".
The basic problem that has come up is the following:
A.hpp ==== #include some serialization headers export, nvp, etc. class A { serialize(..) };
Before implementing this rule, any program which included A.hpp would require linking with the serialization library to build. This was provoked by the auto-linking facility. This would occur even if serialization wasn't used in the program. The made it amost impossible to have a "library" of classes which could be imported into various programs.
I don't get this. Why including
a) I'm very much in agreement with the idea that the meer inclusion of a header shouldn't trigger the requirement of compilation against a library which isn't used. I realize that this is only a problem on compiles which support some sort of auto-link pragma.
I don't see how header order affects this. Can you elaborate? - Volodya