The thread class derives from boost::noncopyable. While this works for static library builds, there are some ugly warnings when compiling user programs that use the DLL version of the threading lib. I suspect noncopyable not having the appropriate __declspec(export) in a DLL being the culprit. I suspect any library will show this behaviour when doing a DLL build. Is this effect known? Are the warnings avoidable? Thank you, Roland
John Maddock wrote:
I suspect any library will show this behaviour when doing a DLL build.
Is this effect known? Are the warnings avoidable?
It's known, but the warnings can be suppressed with some #pragmas around the derived class.
Wouldn't it be better to change the class to use the __declspec(export) as others do? Or would this not solve the problem? At least I am unsure what would happen when trying to mix DLL and static boost libs that both derive from noncopyable. BTW. this seems to me only a special case to a more general question. When using a DLL version of a class that derives from some other class, this would force every other lib that uses the same base, also to be used in DLL version. Is this correct? Roland
Wouldn't it be better to change the class to use the __declspec(export) as others do? Or would this not solve the problem? At least I am unsure what would happen when trying to mix DLL and static boost libs that both derive from noncopyable.
I think it would be OK to delare an all-header class as __declspec(dllimport), but I'm not completely sure (where does the RTTI information end up if there is no source file? I think this normally gets placed in the cpp file that has the first non-inline member function, but I'm not completely sure).
BTW. this seems to me only a special case to a more general question. When using a DLL version of a class that derives from some other class, this would force every other lib that uses the same base, also to be used in DLL version. Is this correct?
Correct, the problem comes when you're using third party code, which uses other third party code and so on, just try using std::list<myclass> in an exported class and you'll see what I mean. See also the discussion of dependencies at http://www.boost.org/more/separate_compilation.html#dlls John.
John Maddock wrote:
Correct, the problem comes when you're using third party code, which uses other third party code and so on, just try using std::list<myclass> in an exported class and you'll see what I mean. See also the discussion of dependencies at http://www.boost.org/more/separate_compilation.html#dlls
Thanks you for the pointer. I assume the pragmas should surround the usage of the base class then rather than the definiton? Correct? I.e.: #ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660) #endif class BOOST_THREAD_DECL thread : private noncopyable { // code here } #ifdef BOOST_MSVC #pragma warning(pop) #endif Roland
Thanks you for the pointer. I assume the pragmas should surround the usage of the base class then rather than the definiton? Correct?
I.e.:
#ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660) #endif
class BOOST_THREAD_DECL thread : private noncopyable {
// code here }
#ifdef BOOST_MSVC #pragma warning(pop) #endif
Correct. John.
participants (2)
-
John Maddock -
Roland Schwarz