RE: [boost] Problem with C4267 & boost::format @ warning level 4, VC 7.1

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-12-13 17:41:28

I fear you are raising the bar excessively to _insist_ on warning free code.
But there is growing support

1 to reduce the number of warnings where possible, and

2 to disable warnings primarily to document belief that the warning is not
significant.

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), and
3 those we should try to avoid (by addition to code),

 and

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

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

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

When you take the address of a function with the __stdcall calling convention,
you must give a prototype so the compiler can create the function's decorated
name. Since function has no prototype, the compiler, when creating the decorated
name, assumes the function has no parameters.

(No example given).

(I presume the original C4267 is a typo for C4276?)

Suggestions on waht to do about this?

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

The controlling expression of an if statement or while loop evaluates to a
constant. The code in the body of the if statement or while loop always executes
or never executes. The following sample generates C4127:

// C4127.cpp
// compile with: /W4
int main() {
   if (1 == 1) {   // C4127, constant expression
   }
}

This is very common and I believe for Boost code it should always be ignored.
It has no run-time cost? (Or has it in debug?)

3  Compiler Warning (level 3) C4511 'class' : copy constructor could not be
generated

The compiler could not generate a default copy-constructor for a class; a base
class may have a private copy-constructor.

Derive class myClass : public boost::noncopyable?

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

4  Compiler Warning (level 4) C4512'class' : assignment operator could not be
generated

The compiler cannot generate an assignment operator for the given class. No
assignment operator was created.

An assignment operator for the base class that is not accessible by the derived
class can cause this warning.

To avoid this warning, specify a user-defined assignment operator for the class.

The compiler will also generate an assignment operator function for a class that
does not define one. This assignment operator is simply a member wise copy of
the data members of an object. Because const data items cannot be modified after
initialization, if the class contains a const item, the default assignment
operator would not work.

For example, the following code generates C4512:

// C4512.cpp
// compile with: /EHsc /W4
#include <iostream>
using namespace std;
class base
{
   const int a;
public:
   base(int val = 0) : a(val)
   {
   }
   int get_a(void)
   {
   return a;
   }
};   // C4512

int main()
{
   base first;
   base second(5);

   cout << "First = " << first.get_a() << endl;
   cout << "Second = " << second.get_a() << endl;
}
You can resolve the C4512 warning for this code in one of three ways:

Explicitly define an assignment operator for the class.
Remove const from the data item in the class.

Reece Dunn suggests:

#include <boost/noncopyable.hpp>

   class base: public boost::noncopyable
   {
      // ...
   };

and this does work for lexical cast, surpessing 29 warnings in my test program.

  class lexical_stream : public boost::noncopyable

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

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

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

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 this.)

8  How to suppress warnings?

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

// push.hpp

#if _MSC_VER
#  pragma warning( push ) // Save current warning dis/enables
#  pragma warning( disable : 4290 ) // C++ exception specification ignored
except to indicate a function is not __declspec(nothrow)
#  pragma warning( disable : 4512 ) // assignment operator could not be
generated
   // ...
#else
   // other compilers
#endif

// pop.hpp

#if _MSC_VER // Or should this be BOOST_MSVC?
#  pragma warning( pop )
#else
   // ...
#endif

Views?

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
mailto:pbristow_at_[hidden]

 -----Original Messages
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Reece Dunn
| Sent: Saturday, December 06, 2003 1:09 AM
| To: boost_at_[hidden]
| Subject: RE: [boost] new compile-time dimensional analysis and unit
| library
|
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Bruce Johnston
| Sent: Tuesday, December 09, 2003 7:42 PM
| To: boost_at_[hidden]
| Subject: [boost] Problem with C4267 & boost::format @ warning level 4,VC 7.1
|
| When attempting to build some code using boost::format(), I get several
| warnings, all C4267. I'm using VC 7.1, warning level 4, and "treat warnings
| as errors" (this is a requirement of the project I'm working on).
|
| I posted a while ago in the user's list asking about some warnings with
| lexical_cast -- namely, warnings C4127, C4511, and C4512.

#ifdef _MSC_VER
#  pragma warning (disable : 4127) // conditional expression is constant
#  pragma warning (disable : 4511) // copy constructor could not be generated
#  pragma warning (disable : 4512) // assignment operator could not be generated
#endif

| I was told these
| are disabled for actual development builds of Boost. Does this imply that
| C4267 is disabled as well? Is there any place where I can get a list of the
| warnings that are disabled under VC 7.1?
|
| It worries me somewhat to see too many warnings disabled. It begins to
| nullify the benefits of using a higher warning level.
|
| -Bruce Johnston
| Simba Technologies