Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-12-15 18:19:34

Paul A Bristow wrote:

>Would it be useful to draw up a list of warnings that
>1 we always ignore,
>2 those that we never ignore (means that the code needs some improvement),
>3 those we should try to avoid (by addition to code),

I agree

>4 to agree a 'Boost Standard' way to disable warnings.

This would help.

>To start a discussion, I have extracted below some common warnings info
>MSVC 7.1 :

>1 Compiler Warning (level 1) C4276'function' : no prototype provided;
>no parameters

Not come across this one. An example would be useful. What libraries are
generating it?

>2 Compiler Warning (level 4) C4127 conditional expression is constant

I'd try and keep the area where the disabling occurs to a minimum, so, using
your example:

// C4127.cpp
// compile with: /W4
int main() {
# include <boost/warn/disable.hpp> // suppress warnings
   if (1 == 1) { // C4127, constant expression
# include <boost/warn/enable.hpp> // restore old warning settings

>3 Compiler Warning (level 3) C4511 'class' : copy constructor could not be
>4 Compiler Warning (level 4) C4512 'class' : assignment operator could not

>Derive class myClass : public boost::noncopyable?

I would prefer this (or defining the members explicitly) to supressing these
warnings. I personally feel that it is lazy to supress these warnings, when
they are easily solvable, and would lead to sloppy programming. NOTE: other
people are free to disagree with this :).

>Run-time cost?
>Does it have a compile-time cost that out-weighs disabling the warning?

Not sure.

>5 #pragma warning(disable: 4100) // unreferenced formal parameter
>harmless, but one could argue that it should be avoided by removing the
>parameter name:

Or commenting it out, if you want to have the name in the parameter list.

>6 #pragma warning(disable: 4702) // unreachable code
>This implies some untidy code.

True. This warning should not in my opinion be suppressed.

>7 //#pragma warning (disable : 4701) // local variable may be used without
>having been initialized
>Rather undesirable. (Can be re-written to cure, but may be annoying to do

I would personally vote in favour of fixing the code.

>8 How to suppress warnings?

>Reece Dunn proposed a way of providing this for MSVC which looks OK to me:

>#if _MSC_VER // Or should this be BOOST_MSVC?


If you want me to have a go at implementing a version of my suggestion and
posting it, I will do. I shall use BOOST_MSVC in it. Also, file names? Do
the following seem okay:

boost/warn/disable.hpp and boost/warn/enable.hpp


boost/warn/supress.hpp (sp?) and boost/warn/restore.hpp

I agree that there should be some sort of configuration -- a strictness

Reece H Dunn

Find a cheaper internet access deal - choose one to suit you.

Boost list run by bdawes at, gregod at, cpdaniel at, john at