From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-02-06 04:44:55
The following have proved useful to reduce the flood of warnings
compiling with level 4, but still give some useful warnings.
Was essential to allow Dinkumware STL to be compiled, but later
versions compile without warnings.
I put these in a file warnings.h in the system files area
and #include <warnings.h> in many builds.
Paul A Bristow, hetp Chromatography
// Suggested file to include to warn about doubtful code
// even if warning level set at 3 lowest that allow C++ standard library
// to be compiled without flood of warnings.
#pragma warning(2:4032) // function arg has different type from
#pragma warning(2:4092) // 'sizeof' value too big
#pragma warning(2:4132 4268)// const object not initialized
#pragma warning(2:4152) // pointer conversion between function and data
#pragma warning(2:4239) // standard doesn't allow this conversion
#pragma warning(2:4701) // local variable used without being initialized
#pragma warning(2:4706) // if (a=b) instead of (if a==b)
#pragma warning(2:4709) // comma in array subscript
#pragma warning(3:4061) // not all enum values tested in switch
#pragma warning(3:4710) // inline function was not inlined
#pragma warning(3:4121) // space added for structure alignment
#pragma warning(3:4505) // unreferenced local function removed
#pragma warning(3:4019) // empty statement at global scope
#pragma warning(3:4057) // pointers refer to different base types
#pragma warning(3:4125) // decimal digit terminates octal escape
#pragma warning(2:4131) // old-style function declarator
#pragma warning(3:4211) // extern redefined as static
#pragma warning(3:4213) // cast on left side of = is non-standard
#pragma warning(3:4222) // member function at file scope shouldn't be
#pragma warning(3:4234 4235)// keyword not supported or reserved for future
#pragma warning(3:4504) // type ambiguous; simplify code
#pragma warning(3:4507) // explicit linkage specified after default
#pragma warning(3:4515) // namespace uses itself
#pragma warning(3:4516 4517)// access declarations are deprecated
#pragma warning(3:4670) // base class of thrown object is inaccessible
#pragma warning(3:4671) // copy ctor of thrown object is inaccessible
#pragma warning(3:4673) // thrown object cannot be handled in catch
#pragma warning(3:4674) // dtor of thrown object is inaccessible
#pragma warning(3:4705) // statement has no effect (example: a+1;)
> -----Original Message-----
> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> Sent: 05 February 2001 17:13
> To: boost_at_[hidden]
> Subject: [boost] Re: Regexp++ 3.03: where is the type.hpp header file?
> --- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
> > Paul Selormey wrote:
> > > I understand the whole boost effort is about standard library.
> > > However, I am working currently on an MFC component, and the users
> > > require level 4 compilation.
> > I'm confused. What's "level 4 compilation"?
> Compiling with VC++ set to "warning level 4", the highest available
> setting. The "default" is level 3.
> > > To achieve this without extensive use of #prama(...) in the
> > > I try to avoid the standard stuff. The regexp++ headers are
> > > in my precompiled header enclosed in #prama(...).
> > So it seems that your particular environment requires #pragma's
> > around the regexp++ headers to compile. So be it; far worse
> > have been effected for MSVC.
> His complaint is with the need for #pragmas in user code when using
> the STL. However, this is an artifact of the STL shipped with VC++.
> The latest Dinkumware library compiles with no warnings at level 4.
> So this is even less of a concern for Boost for many reasons.
> > > The last time I compiled the Regexp++ with the level 4 (before the
> > > boost effort and have reported this to you), I had over 5000
> > Ah, "level 4" refers to some mode enabling lots of warnings. Are
> most of
> > these warnings being provoked by the standard library or by the
> > expression library?
> Probably by both, though I've not compiled Regexp++ code yet.
> Frankly, level 4 produces a lot of spurious warnings on template
> code, especially in Debug builds (where even level 3 will produce
> more warnings than you can shake a stick at). It's my understanding
> that MS is addressing this in the next release. Again, a non-issue
> for Boost.
> > If it's from the former, complain to your vendor. As a side note,
> > just compiled the regression test for the latter with gcc's "-Wall -
> > flags, which enables pretty much all warnings gcc knows about.
> > that resulted in only very few warnings (mostly signed/unsigned
> VC++ isn't so kind, but it's not something that should be addressed
> by Boost.
> > > My humble request was for us to work with the old method of
> > > instead of the new standard stuff.
> > Your desire to avoid the C++ standard library seems to indicate
> that the
> > standard headers are provoking a sizeable proportion of the warnings
> > you give the impression not to like. Note, however, that boost
> > are designed to work well with the C++ standard library and not to
> > it at all cost.
> More importantly, it should be trivial to write a function object
> that works with traditional "C callbacks" with out using the standard
> library. So I don't see a need for modification of Regexp++ in this
> Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk