Re: [boost] VC7/Threads Warnings
Hi all, This discussion was a long time ago, but I didn't get the end of it. As building the thread library I get a lot of warnings I would like to remove them somehow (I'm using the 1.30 release version). So, what would you suggest? Using pragma's is safe enough? If yes, where is the best place to add this ? Thanks, Viv - Original Message - From: William E. Kempf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 1:10 AM Subject: Re: [boost] VC7/Threads Warnings David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. Suggestion: turn them on with #pragmas in the library's test files. This won't turn them on when compiling the library itself, though. Turning them on only for the test files won't catch many of the warnings. So I suggest you use #pragmas in the library implementation files also. My point is that you shouldn't need a custom toolset to see the warnings, and if it's your aim to avoid triggering them they should show up in the Boost regression tests when you do. I guess I'm wondering if the official toolsets shouldn't be changed. I don't understand why the MSDN indicates it should default to /W2 while we're seeing it default to what I assume is /W1. But, projects created by the IDE default to /W3 (which is also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings /Wp64 flag (detect 64-bitportability)
You are probably right - but the tool tip display shows an __int64 which alerted me to this. For most purposes, I suspect this warning /Wp64 is not what most people want.(Or is it Boost policy that code should provide 64-bit portability? Premature?) If one writes: std::size_t s = 42; cout s endl; with MSVC7.0 default project settings for an empty console project on my 32-bit system /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W3 /nologo /c /Wp64 /Zi /TP it is confusing to get a warning: test_size_t.cpp(19) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data (I am unclear why there is a warning unless unsigned int is 32-bit and size_t is 64-bit. How is there a problem if both are 32 or 64?) If one changes to warning level 4/W4 and no test for 64 portability /Wp64 /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP No warnings. And ideally request 'strict' - no extensions and for scope: /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /Za /Zc:forScope /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP Still no warnings. In my experience, carefully written code (which Boost code should be - and generally is) compiled with MSVC 7.0 and warnings at level 4 produces only a few warnings, and those can be individually supressed - and should be as a matter of good documentation. Paul PS Despite RTFM, I cannot see how to change the IDE _default_ solution/project settings. Suggestions? Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Dimov Sent: Wednesday, March 26, 2003 1:58 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings Paul A. Bristow wrote: I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? std::size_t is still 32 bit, /Wp64 generates warnings if the meaning of the code could have changed had size_t been 64 bit. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
- Original Message - From: William E. Kempf [EMAIL PROTECTED] vc said: As for the warnings themselves... I'm still doing more research just to be 100% sure, but everything I've found thus far indicates you can ignore these warnings as long as you link against the same RTL in both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. So, is it ok if for the boost.thread dll and for the app I will use the /MT flag (multi-threaded) instead of /MD (multi-threaded dll) that you are using when building with bjam? According to what I'm reading about these warnings, no, that wouldn't be a good idea. However, you can build against the static RTL easy enough. In the $BOOST_ROOT/libs/thread/build directory issue the following bjam command: bjam -sBUILD=runtime-linkstatic Doing so, the boost.thread will be build with the /MTd flag (for debug). This is exactly what you said that it won't be a good idea, right? Or am I missing something here? If this is not such a good idea (building the boost.thread dll with the /MT flag) what else can I do, as I have my app depending on tons of libs that are already built with /MT flag meaning that all the modules should be built with the same flag (if you mix the modules with the /MT flag and /MD flag, the final app will have links errors) ? Thanks, Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
Paul A. Bristow said: I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? AFAIK and AFAICT, /Wp64 is not used. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
vc said: - Original Message - From: William E. Kempf [EMAIL PROTECTED] vc said: As for the warnings themselves... I'm still doing more research just to be 100% sure, but everything I've found thus far indicates you can ignore these warnings as long as you link against the same RTL in both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. So, is it ok if for the boost.thread dll and for the app I will use the /MT flag (multi-threaded) instead of /MD (multi-threaded dll) that you are using when building with bjam? According to what I'm reading about these warnings, no, that wouldn't be a good idea. However, you can build against the static RTL easy enough. In the $BOOST_ROOT/libs/thread/build directory issue the following bjam command: bjam -sBUILD=runtime-linkstatic Doing so, the boost.thread will be build with the /MTd flag (for debug). This is exactly what you said that it won't be a good idea, right? Or am I missing something here? Sorry, I guess I wasn't very clear (and it looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
Peter Dimov said: William E. Kempf wrote: I guess I'm wondering if the official toolsets shouldn't be changed. I don't understand why the MSDN indicates it should default to /W2 while we're seeing it default to what I assume is /W1. But, projects created by the IDE default to /W3 (which is also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. I agree with the suggestion. The default should be /W3 for VC 6, and /W4 (possibly with some specific warnings disabled) on VC 7+. Why /W4 for VC 7+? The IDE's default is still /W3 on these compilers. I don't think selecting a level different from the compiler's/IDE's default is necessarily a good idea. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
- Original Message - From: William E. Kempf [EMAIL PROTECTED] Doing so, the boost.thread will be build with the /MTd flag (for debug). This is exactly what you said that it won't be a good idea, right? Or am I missing something here? Sorry, I guess I wasn't very clear (and it looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. Thanks a lot for the answer! This is what I wanted to know: If I can build the boost.thread dll and the app with the /MT flag instead of /MD flag. Regarding the mixing of the RTLs the last versions of VC++ gives you a link warning if you try to do that ... Thanks again, Viv -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
William E. Kempf wrote: Peter Dimov said: I agree with the suggestion. The default should be /W3 for VC 6, and /W4 (possibly with some specific warnings disabled) on VC 7+. Why /W4 for VC 7+? The IDE's default is still /W3 on these compilers. I don't think selecting a level different from the compiler's/IDE's default is necessarily a good idea. My opinion only. /W4 was a bit painful for VC 6 (many of us used it anyway) but it seems fairly usable on VC 7. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. I'd expect warningsall to translate to /Wall on VC 7. Not a very practical warning level IMHO. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
Peter Dimov said: William E. Kempf wrote: Peter Dimov said: I agree with the suggestion. The default should be /W3 for VC 6, and /W4 (possibly with some specific warnings disabled) on VC 7+. Why /W4 for VC 7+? The IDE's default is still /W3 on these compilers. I don't think selecting a level different from the compiler's/IDE's default is necessarily a good idea. My opinion only. /W4 was a bit painful for VC 6 (many of us used it anyway) but it seems fairly usable on VC 7. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. I'd expect warningsall to translate to /Wall on VC 7. Not a very practical warning level IMHO. :-) Well, add other options for warnings then ;). warningsnone (disable warnings) warningsdefault (typical warnings) warningshigh (all warnings that aren't considered painful) warningsall (all warnings) Of course, the names and categories would need consideration when viewed portably. For example, warningsall would imply -Wall for gcc, which should also be used for warningshigh (?), so some users might mistakenly use all when they should use high instead. But I think you could come up with a reasonable way to declare this portably, and believe it would be useful. I'd use warningsall from the command line to lint my code with VC (even VC6), but would prefer to leave things at the default level in the Jamfile to more closely meet user's expectations (too low and when they use my code they get warnings we don't report, too high, and when they use bjam on their own code they may get warnings they don't care to see). -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
vc said: - Original Message - From: William E. Kempf [EMAIL PROTECTED] Doing so, the boost.thread will be build with the /MTd flag (for debug). This is exactly what you said that it won't be a good idea, right? Or am I missing something here? Sorry, I guess I wasn't very clear (and it looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. Thanks a lot for the answer! This is what I wanted to know: If I can build the boost.thread dll and the app with the /MT flag instead of /MD flag. Regarding the mixing of the RTLs the last versions of VC++ gives you a link warning if you try to do that ... Nice to know... but it wouldn't work for dynamically loaded DLLs. Then again, dynamically loading Boost.Thread is not a good idea. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
Andrew J. P. Maclean said: I am using Boost Ver 1.30 just released. I built the libraries with BJam. Now when building my code I get lots of warnings like the following. These warnings worry me a bit because they are level 1 and 2 warnings. Is it safe to ignore these or do I need to manually set some option? I never got these warnings with Boost 1.29. There does appear to be something wrong in your setup. I'm going to guess that you're linking against the static RTL? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
As I am having the same problem, I looked a little to the bjam settings, and it seems that, at least when building with VC7.x, the -Wx (warning level) option is not set, that is why probably with bjam these warnings are not seen ... Viv - Original Message - From: William E. Kempf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:39 PM Subject: Re: [boost] VC7/Threads Warnings Andrew J. P. Maclean said: I am using Boost Ver 1.30 just released. I built the libraries with BJam. Now when building my code I get lots of warnings like the following. These warnings worry me a bit because they are level 1 and 2 warnings. Is it safe to ignore these or do I need to manually set some option? I never got these warnings with Boost 1.29. There does appear to be something wrong in your setup. I'm going to guess that you're linking against the static RTL? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. Suggestion: turn them on with #pragmas in the library's test files. This won't turn them on when compiling the library itself, though. Turning them on only for the test files won't catch many of the warnings. So I suggest you use #pragmas in the library implementation files also. My point is that you shouldn't need a custom toolset to see the warnings, and if it's your aim to avoid triggering them they should show up in the Boost regression tests when you do. I guess I'm wondering if the official toolsets shouldn't be changed. I don't understand why the MSDN indicates it should default to /W2 while we're seeing it default to what I assume is /W1. But, projects created by the IDE default to /W3 (which is also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of vc Sent: Tuesday, March 25, 2003 5:20 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings - Original Message - From: William E. Kempf [EMAIL PROTECTED] Yes it seems that in command line by default is W1. If you set the /Wp64 flag (detect 64-bit portability) you will get warnings level 1 and they can be seen using bjam without setting the Wx flag. So, seems that W1 is by default ... Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
For your information I also get these warnings when building using bjam. As you mention below - ignoring the warnings seems OK in my code (but it is simple stuff). Is it possible to create a static library? I suspect that the defines prevent this. This was possible in version 1.29. Obviously this is not for the monitor but when not using the monitor it would be nice to have a static library to link in. Then I don't have to worry about making sure the dll is present. Andrew ___ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.cas.edu.au/ ___ -Original Message- From: William E. Kempf [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 March 2003 03:29 To: [EMAIL PROTECTED] Subject: Re: [boost] VC7/Threads Warnings vc said: As I am having the same problem, I looked a little to the bjam settings, and it seems that, at least when building with VC7.x, the -Wx (warning level) option is not set, that is why probably with bjam these warnings are not seen ... Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. As for the warnings themselves... I'm still doing more research just to be 100% sure, but everything I've found thus far indicates you can ignore these warnings as long as you link against the same RTL in both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
