Thorsten Behrens wrote:
Hi folks,
while trying to get basebmp and vigra warning free, I've been bitten
by the following two msvc warnings:
---------------------------------------------------------------------
Compiler Warning (level 3) C4686
'user-defined type' : possible change in behavior, change in UDT
return calling convention
A class template specialization was not is defined before it was used
in a return type. Anything that instantiates the class will resolve
C4686; declaring an instance or accessing a member (C<int>::anything)
are also options.
---------------------------------------------------------------------
Compiler Warning (level 4) C4668
Error Message 'symbol' is not defined as a preprocessor macro,
replacing with '0' for 'directives'
A symbol that was not defined was used with a preprocessor
directive. The symbol will evaluate to false. To define a symbol, you
can use either the #define directive or /D compiler option.
---------------------------------------------------------------------
C4686 is one of those infamous 'let's warn our users, because we've
changed behaviour and fixed a nonconformant behaviour' MS noise
generators (it's about which calling convention is used for the
not-yet-instantiated return type). I'd say could safely be disabled.
Agreed that such warnings should be disabled globally. (I also want to
disable "warning C4347: behavior change: 'overload A' is called instead
of 'overload B'" on CWS sb59, which is for example triggered by some
instances of std::min<sal_Int32>(a,b).)
C4668 can potentially unearth real portability problems (that a try to
access an undefined preprocessor macro evaluates to '0' is a
convention possibly not shared by all c++ compilers of this universe)
This behavior is not a convention, but mandated by the C/C++ standards.
Still, in all the cases I encountered so far where MSC issued this
warning, it either (a) unearthed really broken code like #if
STRCODE==sal_Unicode in tools/source/string/strimp.cxx:1.7, (b) was easy
to either fix the offending #if FOO to something like #ifdef FOO (which
appeared to be the intended code, and the original author had merely
been sloppy), or (c) was easy to wrap the offending (external) header in
some disable-warnings #pragma (which was needed anyway, as the external
header also produced other warnings). Thus, I am reluctant to disable
this warning globally.
- unfortunately, it's implicitely relied upon by boost's
BOOST_WORKAROUND macro (boost/workaround.hpp). Since no other compiler
warns about that, I've no idea how to fix BOOST_WORKAROUND, and this
macro's use is quite abundant in boost, I'd also suggest disabling
it. This could be temporary, until upstream boost has
fixed/workarounded this.
Would it work to disable that warning locally within boost headers?
Last, but not least there's a really annoying side effect of gcc's
-Wshadow warning: when declaring functions that overload one of the
gcc builtin functions, you get the following warning issued:
stl/stl/_complex.h:782: warning: shadowing built-in function `int
std::abs(int)'
Switching off -Wshadow cures this, as well as disabling gcc's builtins
via -fno-builtin. But both prolly aren't changes we want to do
persistently for gcc. Any other ideas?
We already sprinkled our STLport patches with pragmas to disable
warnings locally within those headers. Seems this is just yet another
place where we need to do that.
-Stephan
Thanks for listening, feedback greatly appreciated,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
