On Linux, I develop usually with
-pedantic -ansi -strict -Werror -Wall which makes basically any warning an error and turns on virtually all available warnings (unused variables, anyone?). Most of the time the Linux programs were rather small though. Yesterday, I tried the same (i.e. warning level 4) on Windows. Read on for results.
Warning level 4 - the cutting edge
Warning level 4 is above the default level, and it is there for a good reason. You will get a lot of warnings, no matter how good your code is, the good thing is that you usually wind up with 3-4 bogus warnings you can disable and if your code is standards-conforming and well written, that should have been it.
Warnings I disable by default
'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'. This appears for things like
boost::noncopyable. As long as your know that your clients will have the interface in question, you can safely ignore that.
non DLL-interface classkey 'identifier' used as base for DLL-interface classkey 'identifier'. Basically the same as above.
'identifier1' has C-linkage specified, but returns UDT 'identifier2' which is incompatible with C. Happens as you you have an
external "C"function which returns a C++ class. As long as you know that your clients will use C++, this can be ignored.
Disabled warnings from level 4
conditional expression is constant. Actually I didn’t want to disable it, but unfortunately it crops up all the time in
boost::lexical_cast. It’s not that bad to disable it because mistakes like
a = binstead of
a == bwill be caught by a different warning.
assignment operator could not be generated. Well, that’s bad luck, but you’ll notice it anyway when you try to assign it, if you don’t try, then you probably didn’t want it.
default constructor could not be generated. Crops up when you define a
const char*member. Yeah, it cannot be default initialized, but as usual, you’ll get an error if you try to.
struct 'indentifier' can never be instantiated - user defined constructor required. Same as above.
With this warnings disabled I’ve been able to recompile niven without warnings, and I found a bug! In one function, I haven’t used a formal parameter which was now highlighted as a warning and was indeed a real bug. So, turning you warning level up to 4 can be really helpful!