Edward Diener wrote:
Thanks for the explanation. Although I really dislike header file dependencies, the rule that you have about including archive headers before serialization headers is easy to understand.
Regarding the partial specialization and no-RTTI problems, and without knowing your internal code, I would just like to suggest that for those using conforming compilers and RTTI you should strive not to impose the header file ordering rule of having the header archives files included before the header serialization files. I realize you are doing this, even in this case, anyway because the BOOST_CLASS_EXPORT("class") works properly with the rule, but I would still seek to eliminate this header
Its generally underestimated how much effort it takes to make something like this work on a wide variety of platforms. In order to accomplish this one sometimes tries for the least common denominator. Other times different code is used for different platforms. One fixed point that I tried to maintain is that it be possible that one can write code that will work on all platforms that boost supports. I viewed this as essential to permit other library writers to serialization modules for their classes once and only once. This sort of supports the lowest common denominator approach which I tend to favor.
file dependency for conforming compilers and those who naturally use RTTI.
I should say I wasn't crazy about providing an alternative to RTTI. But I ended up doing it for a couple of reasons. I had a list of criticisms to address from the first rejection. There were a number of other criticism that I wasn't crazy about addressing either. But in addressing each of these one by one, I came to change my mind and see them as better ideas and making a better package. The last one was no-rtti. I thought this was really not worth the effort but then I thought - hmmm, that's what I thought about the others also. So, I'll experiment and see what happens. I factored out the extended_type_info code as separate header and implementation and made a non-rtti implementation. I still wasn't convinced it was a valuable feature. But it did isolate a fundamental piece in a more logical, and understandable and modular piece. So I left it it. It turns out that this plays a key part in "user" code - new serialization of shared_ptr so now I have to add extended_type_info to the documentation - sort of pain. I don't have a real point here. I'm just trying to convey how things get to where they are and how its not always easy to make a concise rationale for the way things are.
Do not think, by saying the above, I do not applaud your heroic efforts to get serialization to work with non-conforming compilers and those people who prefer to turn off RTTI, but only that there must come a point where those who use standard C++ should not face any of the restrictions of those who do not. Not that it is necessarily the programmer's fault that their compiler is deficient, or that they must not use RTTI for some reason, but I consider both non-standard C++.
For better or worse, this is a feature of the boost process. In order to get a library accepted, almost every requested requirement has to be accomodated unless it directly conflicts with some other requested feature. Net result is a library which covers far more than any one programmer or project needs. When someone makes a "strong" case for a some arcane but hard to implement "feature", there is no one (other than the library author) with a strong case for not doing it. And the library ends up including almost everything. (Oh don't forget compile time and run-time performance as well) The difficulty of getting a library accepted grows disproportionatly to its size and the number of people that might be interested in it. I'm not saying this is necessarily a bad thing. That's just the way it is.
As a long shot, and again not knowing the internals, is it not possible to have BOOST_CLASS_EXPORT("class") work as each archive is included, perhaps by including export.h at the end of each of your own archives and building the exported information one at a time ? No I am not trying to create extra work for you <g>, but just suggesting future possibilities to eliminate the very reasonable header file rule you have.
I never considered such an idea so its hard to comment on. During the first review there was a lot of objection that modules were way too big. So I made effort so that one only had to include what one used. So one only has to include export.hpp if and only if BOOST_CLASS_EXPORT is in fact being used. That's how we got here. Robert Ramey