Vladimir Prus wrote:
Oh.. Okay, I think I'm starting to understand what's going on. 1. For BOOST_EXPORT used in headers, you want the list of archive classes 2. So, you want archive headers to be included before the header that contain BOOST_EXPORT. 3. You generalize the above requirement to "all archive headers must be included before all serialization headers".
Is my understanding correct?
Yes.
If so, then I'd say this: 1. I don't have any magic solution for "archive headers must be included before BOOST_EXPORT" problem. One possibility would be to disallow BOOST_CLASS_EXPORT in headers -- after all exporting makes sense only for concrete classes (non-abstract), and so they have some code, and some .cpp module to invoke BOOST_CLASS_EXPORT there. Another would be to auto-register with polymorphic_archive as I've suggested previously. (Oops, I think I forgot to reply to your last post on that topic).
It has been my view that BOOST_CLASS_EXPORT is really sort of class trait - assign GUID to the class and as such it should be part of the header so that the module can be included by different programs and they will all share the same GUID. (GUID= Globally, Unique IDentifier). I went through extra effort to permit this. However, it doesn't have to be in the header. I don't see any conflict if you have it in some other module.
2. I'm not really happy with generalization. I still believe (although may be wrong), that including
and many other <serialization/> headers is possible without invoking auto-linking. Since not users want BOOST_CLASS_EXPORT at all, or want it in headers, this will reduce the number of "what's up with header" order questions you get on this list.
Sorry, but it seems that the BOOST_CLASS_EXPORT issue exists regardless of auto-linking, no?
This is correct and somewhat confusing. They are unrelated issues - but I "fixed" them with the same solution - imposing a requirement on header sequence. This makes them seem more related than they are.
And seems I've finally understood your rationale.
I'll add an explanation of this topic to the "rationale" section of the manual. This discussion has made me think about this a little bit more. I haven't considered the implications in detail, but my current thought is: a) note that BOOST_CLASS_EXPORT does not have to be in a header module. I'm pretty sure this is true but it should be checked. I think this would address one of your concerns. b) The #error .... for archive/serialization header inclusion can probably be made conditional on whether auto-linking is disabled. There is a macro defined or not BOOST_NO_AUTO_LINKING(?) which will suppress auto-linking. In that case the auto-link problem can't occur so no requirement for header inclusion need be enforced. I didn't have to make a huge number of changes to make auto-link work the way I wanted - it just took some time to sort out the side-effects and find the right places to change. So I would expect I can spice up the header inclusion with conditionals that depend upon auto-linking. So in your case, you can get the original behavior by foregoing auto-linking - which isn't available with your platform of choice (gcc?) anyhow. Also your code would still be portable to other compilers with restriction that the library to link to would have to be specified explicitly. I think this would be a satisfactory situation all around. Robert Ramey