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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to