Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2003-04-30 05:30:45


On Wed, Apr 30, 2003 at 10:24:09AM +0100, Ken Hagan wrote:
> > William E. Kempf wrote...
> >> pragmas. As a "best practice suggestion", it's a great idea... as a
> >> requirement, I'd have to voice an opinion against.
>
> Paul A. Bristow wrote:
> >
> > I absolutely agree, but I feel it would be useful encourage authors
> > to try.
>
> Playing devil's advocate, but why?
>
> With the compiler in question, I can write
>
> #pragma warning(push)
> // lower the warning level
> // include dodgy headers
> #pragma warning(pop)
>
> and I do exactly this for all my third party headers. I don't know
> if other compilers have this push/pop feature, but they ought to.
> (In fact, I can't think of a pragma that wouldn't benefit from
> being able to push and pop its effects.)
>
> Also, if I run LINT on my code I get warnings about things that
> my compiler never worries about. I have to tell LINT to ignore
> the quality of third party headers too. Are we suggesting that
> boost authors write "//lint" comments too? Where does it stop?
>
> I use compiler warnings to point me at risk areas in my code.
> Boost has been tested rather more thoroughly than my own code
> (sad to say) and doesn't feature highly in my risk assessment,
> so I'm going to lower the warning level for those headers anyway.
>
> Given that, there isn't much point in boost authors writing lots
> of "line by line" warning suppression paragmas.
>

I have noticed a lot of new warnings in the release 1.30.
I absuletely agree, that there is no reason to do some kind of "line by line"
pragma suppression.

But...

Most of the new warnings can be easily removed with a static_cast. I don't understand,
why any boost lib have to generate such a warnings.

Pavol


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk