After some tests I made something like Peter suggested. For best results it was necessary to make separate code for debug and release version. Here is full macro:
#define TTRACE_IF(Area, Level, Action) \
do { \
if (TdbgIsLogAllowed(&TdbgArea_##Area, Level)) { \
try { \
Action; \
_TDBG_PRETEND_POSSIBLE_EXCEPTION; \
} \
catch (…) { \
TTRACE(Area, Level, (“Unknown exception occured inside TTRACE_IF block.”));\
} \
} \
} while (0)
and helper macros:
#ifdef NDEBUG
// release version
__forceinline bool _TdbgPretendPossibleException() {
return(false);
}
#define _TDBG_PRETEND_POSSIBLE_EXCEPTION \
do { \
if (_TdbgPretendPossibleException()) throw(0); \
} while (0)
#else
// debug version
inline void _TdbgPretendPossibleException() {
}
#define _TDBG_PRETEND_POSSIBLE_EXCEPTION \
_TdbgPretendPossibleException()
#endif
For release compilation no additional code is generated. Even catch block is omitted if Action can’t throw an exception. For debug compilation there is no additional code in try block but catch block is generated always. It is no problem. If current release code was used for debug compilation, it generated code necessary to throw exception. That’s why I made it different.
It is amazing what has to be done for something as obvious: disable a warning for given macro expansion. Maybe it isn’t quite easy but PC-lint shows it isn’t impossible. Also, compiler shouldn’t crash with internal error 1001 if previous compilation generated something odd. Today I saw it many times.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, June 23, 2004 5:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to disable warning for a macro?I like to declare an inline function that returns true. The compiler
sees this as a real choice when processing this warning and the code
optimizer could potentially optimize out the entire branch when it
merges the inline function into the call site.The optimizer can’t optimize out the branch if you use a global variable
because it could be changed, and I think the analyzer will determine
that you’re trying to trick it if you declare the variable as const (not
to mention that const is meaningless since it can be casted away so I
bet the optimizer won’t care about it)I ***believe*** I’ve successfully made the compiler do this before. I
don’t remember entirely and I don’t have time right now to do an
experiment, but you might give it a try.-p
This posting is provided “AS IS” with no warranties, and confers no
rights.