Emil Dotchevski wrote: ... elision by patrick... This assumes that a policy that requires warnings to be "fixed" is desirable or that it will lead to a better Boost (note that I'm not arguing against disabling warnings in Boost headers.) It's a safe assumption. Having been through this pain a number of times I know that it leads to consistently better code. I've seen it many times. In fact yesterday, coincidently, (or not, it was because I was talking to him about this discussion), I was working through the code of someone I highly respect as a programmer with decades of experience who's sat on a couple of different language standard committees, and while getting rid of warnings in his code, I found some real bugs. Had he been used to running at a high warning level, those bugs wouldn't have crept into his code. This didn't surprise me a bit. It always happens. You start building with higher warning levels on any large body of code and you always find real bugs. That's the point of it. A couple of them were really obvious, once the messages pointed me to them, but of course you know how our eyes see what we expect. A lot of the warnings were annoying and made me do silly things, like reverse a condition so that I could move a throw up and a return down. Some of them were technically bugs, like comparisons between signed and unsigned but in the problem domain we knew that the bug would never be hit, but still bad code, and sometimes you get data outside the problem domain--surprise! Eventually I got it down to multiple copies of a warning out of boost/archive/binary_oarchive.hpp signed vs unsigned conversion just from including it. Frustrating. In the next day or two I'll get back into it and figure that out (it's a line in basic_binary_oarchive::save_override). You might think that a waste of time, but it's not. The point is that now the code can be built normally with a higher warning level, and now that I've gotten rid of most of the noise, except for boost noise, more bugs will be caught before they get out in the wild. It's obvious that you don't like it. I know. It's a pain in the ass. But--there are real and large benefits that will help you and those that come after with this code for as long as people are building it and building with it. The potential payoff is huge! Just silencing all the warnings by disabling them means that you don't get the advantage that building with higher warning levels brings you. Certainly, if that's all you were going to do, it would pointless. If you're sure a complaint is a bug for the compiler that generates the warning, write a bug against them, but silence it for your users. Make sure if you do that that you revisit silencing it after the compiler writers fix their bug. Patrick