"Francis ANDRE" <francis.andre@easynet.fr> wrote in message news:cmaonj$7o1$1@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