From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2008-04-02 09:25:24
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk