#pragma warning (dsiable : 4996) ineffective?
I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings. However this seems not to work (at least on my machine). There seems to be some unintended interdependence with _SCL_SECURE_NO_DEPRECATE. I was not able to find out what exactly is causing the warnings not go away. Hoever, compiling with _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE quiets the build. Couldn't this issue be handled by the boost config headers? Is this something wrong with my setup only, or do others experience the same problem? Thank you, to anyone who cares. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz <roland.schwarz@chello.at> writes:
I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings.
However this seems not to work (at least on my machine).
It works here, that's why I put it in.
There seems to be some unintended interdependence with _SCL_SECURE_NO_DEPRECATE. I was not able to find out what exactly is causing the warnings not go away.
Hoever, compiling with _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE
quiets the build.
Yes, that works too, but it's a build option.
Couldn't this issue be handled by the boost config headers?
That would seem better than handling it on a case-by-case basis, but it might change things for user code too (i.e. any code included *after* the boost headers).
Is this something wrong with my setup only, or do others experience the same problem?
There must be something different with our setups. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
We have to manually change the boost build files to specify that we want everything built with -D_SCL_SECURE=0. Without this we hit runtime errors when iterators form part of the interface to a lib (the specific issue was with signals, but it applies in the general case too). I'd like to see the boost build system provide the option of specifying an _SCL_SECURE=0 define at the command line, I don't think this is possible at the moment. Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Anthony Williams Sent: 31 March 2008 21:32 To: boost@lists.boost.org Subject: Re: [boost] #pragma warning (dsiable : 4996) ineffective?
Roland Schwarz <roland.schwarz@chello.at> writes:
I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings.
However this seems not to work (at least on my machine).
It works here, that's why I put it in.
There seems to be some unintended interdependence with _SCL_SECURE_NO_DEPRECATE. I was not able to find out what exactly is causing the warnings not go away.
Hoever, compiling with _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE
quiets the build.
Yes, that works too, but it's a build option.
Couldn't this issue be handled by the boost config headers?
That would seem better than handling it on a case-by-case basis, but it might change things for user code too (i.e. any code included *after* the boost headers).
Is this something wrong with my setup only, or do others experience the same problem?
There must be something different with our setups.
Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
Anthony Williams wrote:
Couldn't this issue be handled by the boost config headers?
That would seem better than handling it on a case-by-case basis, but it might change things for user code too (i.e. any code included *after* the boost headers).
It's also fragile: it only works if the Boost header is the first header included, and if that header doesn't include any std lib headers before boost/config.hpp :-( John.
Roland Schwartz wrote:
I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings.
However this seems not to work (at least on my machine).
How does the pragma work? Does it disable all warnings, or only warnings in subsequent declarations? Does the warning state apply when a template class is declared or instantiated? John Maddock wrote:
Anthony Williams wrote:
Couldn't this issue be handled by the boost config headers?
That would seem better than handling it on a case-by-case basis, but it might change things for user code too (i.e. any code included *after* the boost headers).
In VC8, there is #pragma push_macro and pop_macro
It's also fragile: it only works if the Boost header is the first header included, and if that header doesn't include any std lib headers before boost/config.hpp :-(
But what if there is other truly deprecated code? Isn't disabling the macro much more specific than disabling all warnings for all deprecated code? -- John Femiani
How does the pragma work? Does it disable all warnings, or only warnings in subsequent declarations? Does the warning state apply when a template class is declared or instantiated?
In Visual Studio 2005 / 2008 (8 & 9) the pragma for warnings takes effect on the next top-level declaratation; it is essentially ineffective inside a function or class definition. The binding to spans of source text appears to be quite robust with respect to compiler passes; I have not observed any leakage. On the last point, it appears that if the template definition has a warning disabled, that warning will not be emitted during instantiation. I could easily be wrong about that though, I can't recall having looked into it explicitly. But if it were not the case I believe I would have seen a counterexample by now. On the other hand, we have seldom disabled warning that are emitted late in the compiler; anything that takes that much analysis to generate is usually something you want to fix.
But what if there is other truly deprecated code? Isn't disabling the macro much more specific than disabling all warnings for all deprecated code?
Yes, much better to use the 3-or-4 macros provided to turn off the security and POSIX deprecations. The deprecation mechanism is available to everybody, not just Microsoft, and there are often very good reasons for using it. Whacking the warning across-the-board throws out the baby with the bathwater. The warning in VS2008 associated with the deprecated command-line option /Wp64 can't be disabled from within the IDE: the flag to disable the warning gets pasted into the command line after the offending flag so the warning has been emitted before the disable command is encountered. There are also some cases where disabling a warning causes the auxiliary informational "pseudo-warnings" associated with it to be orphaned in the output stream. Not the worst compiler I've ever used but it does have its quirks.
John Femiani wrote:
Roland Schwartz wrote:
I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings.
However this seems not to work (at least on my machine).
How does the pragma work? Does it disable all warnings, or only warnings in subsequent declarations? Does the warning state apply when a template class is declared or instantiated?
Only subsequent declarations: and by using #pragma warning(push/pop) you can scope the warning disabling to a specific section of code, while leaving the warning turned on for everyone else (if they want it).
John Maddock wrote:
Anthony Williams wrote:
Couldn't this issue be handled by the boost config headers?
That would seem better than handling it on a case-by-case basis, but it might change things for user code too (i.e. any code included *after* the boost headers).
In VC8, there is #pragma push_macro and pop_macro
It's also fragile: it only works if the Boost header is the first header included, and if that header doesn't include any std lib headers before boost/config.hpp :-(
But what if there is other truly deprecated code? Isn't disabling the macro much more specific than disabling all warnings for all deprecated code?
No the macros are a global setting - the only reliable way to set these is globally on the command line, you can't turn them on and off for specific sections of code. HTH, John.
But what if there is other truly deprecated code? Isn't disabling the macro much more specific than disabling all warnings for all deprecated code?
No the macros are a global setting - the only reliable way to set these is globally on the command line, you can't turn them on and off for specific sections of code.
The "deprecated" attribute gets attached to function names (free or member) when their declarations are parsed. Having the warning disabled (with #pragma warning push / pop) at the point of declaration has no effect, it would have to remain disabled at the call / instantiation point. On the other hand, the macro is used to conditionally disable the deprecation clause on the declarations; it would actually work to define it, include the declaration header, and pop the macro definition. But, as mentioned, it would only work if the "supervising" header were not preempted by an earlier include of the declaring header. Most Microsoft headers are protected by a #pragma once directive which acts like #ifdef THIS_HEADER_ALREADY_INCLUDED except it bypasses the open and preprocessor-parse of the file. Given the relatively high cost of these operations on Windows and the outrageous number of headers that get dragged into typical programs, this is a big win. But it means you can't muck with "context" macros and re-include a header in most cases.
participants (6)
-
Anthony Williams -
James Talbut -
John Femiani -
John Maddock -
Roland Schwarz -
Stephen Nuchia