[boost] Re: [Config] proposal of new macro, BOOST_DECL :follow up for boost::noncopyable & vc7.1 & dll

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-11-03 10:47:43

"Francis ANDRE" <francis.andre_at_[hidden]> wrote in message 
news:cmaonj$7o1$1_at_sea.gmane.org...
>> Except we only have one definition for non_copyable, so what 
>> happens if
>> library X wants it to have a dll interface and lib Y doesn't?  It's 
>> also
> all
>
> You'r right...so a solution could be to ask to the provider of each 
> dll
> boost libraries to embed
> each declaration of an imported class with the followings win32 only 
> pragmas
>
> #pragma warning(disable: 4275 4251)
> class BOOST_THREAD_DECL mutex
> : private noncopyable {
> //....
> };
> #pragma warning(default: 4275 4251)
>
> so that any missing __declspec(dllimport) in any user's dll library 
> could be
> trapped as an error!!

It has been suggested to me that it would be better (for other 
reasons) to mark individual member functions as exported rather than 
marking whole classes. Would that also help in this situation? I 
haven't looked closely yet, but if the individual member functions of 
the thread classes are exported then this warning may no longer be 
generated.

Would there be any problems with changing to this approach?

[snip]

>> Except we only have one definition for non_copyable, so what 
>> happens if
>> library X wants it to have a dll interface and lib Y doesn't?  It's 
>> also
> all
>> inline, so declaring it imported is a little strange.  Maybe some 
>> #pragmas
>
>> to disable the warnings would be better, especially as we can't do 
>> much
>> about:
>>
>> c:\data\boost\develop\boost\boost\thread\thread.hpp(75) : warning 
>> C4251:
>> 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to 
>> have
>> dll-interface to be used by clients of class 'boost::thread_group'
>> with
>> [
>> _Ty=boost::thread *
>> ]

Would exporting only the appropriate member functions help here as 
well?

Mike