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