Re: [Boost-users] Auto-Link issues - was RC1 nvp.hpp gotcha

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-12 11:37:53

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 <serialization/nvp.hpp> 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