warnings in Thread library in 1.30.0 release when compiled by VC
Subject: numerous warnings in Thread library in 1.30.0 release when compiled by VC7.1 (or other vc versions) with warning level 3 or above We're in the process of migrating our project from V1.29.0 to 1.30.0. We are getting a lot of warnings with thread library such as the following: c:\Program Files\Boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll- interface class 'boost::detail::condition_impl' I know very little about bjam but it looks like it doesn't even use /Wn switch (correct me if I am wrong and the default is /W2. IMHO, it seems to me that it is always a good practice to set the warning level to at least 3. Also, we would really really like to have the static library option back. :-) Best regards, Sean
huangsean said:
Subject: numerous warnings in Thread library in 1.30.0 release when compiled by VC7.1 (or other vc versions) with warning level 3 or above
We're in the process of migrating our project from V1.29.0 to 1.30.0. We are getting a lot of warnings with thread library such as the following:
c:\Program Files\Boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll- interface class 'boost::detail::condition_impl'
I know very little about bjam but it looks like it doesn't even use /Wn switch (correct me if I am wrong and the default is /W2. IMHO, it seems to me that it is always a good practice to set the warning level to at least 3.
I believe it uses the default on all compilers? I test with VC6, VC7, VC71, gcc-nocygwin and the free Borland on Windows, and none of them report any warnings. (Well, Borland reports some "unused variable" warnings that I've recently disabled with some brute force command line options.) I don't believe the warning you're reporting is one you should worry about... though I can understand the desire to eliminate it from the compiler output. I'll look into it.
Also, we would really really like to have the static library option back. :-)
*sigh* Noted... but I don't think it's likely to happen. Unless of course you (or anyone else) can come up with a viable way to get TLS cleanup to function with out a DLL implementation. With out that, maintaining two forms of building is just too much effort, and won't really be usable in the next version any way (since thread creation will rely on TLS data that needs cleanup). -- William E. Kempf
Bill, Thanks for the reply.
From what I understand (without looking into the detail implemenation of boost.thread), these warnings can only be safely ignored if we can be sure we use the same version of CRT (dll v.s. static). If this is true, then it essentially means we cannot use boost::thread in applications that statically link to rtl.
Thanks, Sean "William E. Kempf" <wekempf@cox.net> wrote in message news:2485.167.16.75.51.1048202497.squirrel@frodo.kempf-ville.com...
huangsean said:
Subject: numerous warnings in Thread library in 1.30.0 release when compiled by VC7.1 (or other vc versions) with warning level 3 or above
We're in the process of migrating our project from V1.29.0 to 1.30.0. We are getting a lot of warnings with thread library such as the following:
c:\Program Files\Boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll- interface class 'boost::detail::condition_impl'
I know very little about bjam but it looks like it doesn't even use /Wn switch (correct me if I am wrong and the default is /W2. IMHO, it seems to me that it is always a good practice to set the warning level to at least 3.
I believe it uses the default on all compilers? I test with VC6, VC7, VC71, gcc-nocygwin and the free Borland on Windows, and none of them report any warnings. (Well, Borland reports some "unused variable" warnings that I've recently disabled with some brute force command line options.)
I don't believe the warning you're reporting is one you should worry about... though I can understand the desire to eliminate it from the compiler output. I'll look into it.
Also, we would really really like to have the static library option back. :-)
*sigh* Noted... but I don't think it's likely to happen. Unless of course you (or anyone else) can come up with a viable way to get TLS cleanup to function with out a DLL implementation. With out that, maintaining two forms of building is just too much effort, and won't really be usable in the next version any way (since thread creation will rely on TLS data that needs cleanup).
-- William E. Kempf
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
participants (3)
-
huangsean -
Sean Huang -
William E. Kempf