Boost logo

Boost :

From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2008-04-01 15:21:46


> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk