John Maddock wrote: I'm *not* saying we should do this for 1.41, but should we have an official policy regarding compiler warnings and which ones we regard as "failures"? I realize these can get pretty busy-body at times, but if the user sees several pages of warnings when building Boost it doesn't look so good. It not only doesn't look good. It isn't good. As Herb Sutter and Andrei Alexandrescu point out in Item 1 in C++ Coding Standards which says compile cleanly at high warning levels, if you get used to ignoring warnings, it is guaranteed to bite you in the butt. I know people will talk about silly examples, and how hard it is. Wah wah wah. I find real errors in the code of people like that all the time. They got used to ignoring warnings and real problems got by them. Someone who isn't willing to understand the warnings is asking for trouble, and I know there are people in boost who don't take the trouble to understand their warnings. I see things that are silly, and that they should have fixed. I don't see how they can hold their heads up for some of this stuff. Of course, there are silly warnings. Sometimes the problem is with the compiler. But still, make them go away if at all possible, otherwise the noise makes it difficult/impossible to catch the real problems, and all that noise makes you look like a rookie wanna be, not the provider of serious software. In my code, I get rid of all the warnings from compiling at high warning levels. Currently, for one project, I'm using (for gcc) -ansi -pedantic -Wextra -Wwrite-strings -Wformat=2 -Wall. I use a lot of templated code and have a clean compile. Not a single warning. When I started doing that years ago, the quality of my code immediately increased and has stayed much higher ever since. An example of one of my least favorite avoidable warnings is when one part of boost moves an include file and deprecates the old location, and release after release, I have to look at warnings from other parts of boost. I can't even say what I think about that. I don't think a release should go out with issues like that. Boost should at least be internally consistent, and not have warnings about misusing other parts of boost. You'd think that would be the bare minimum to avoid looking like amateurs. How hard would it have been to fix for example, in 1.40 when I see hundreds of warnings from the graph stuff because: boost/property_map.hpp:15:4: warning: #warning "This header is deprecated. Please use: boost/property_map/property_map.hpp" I'm guessing the graph guys are used to ignoring warnings. But the code was released like this. That's embarrassing. There's probably 35 places they would have had to fix this so that hundreds of errors wouldn't spew out whenever someone used their code. They aren't even willing to grab the low-hanging fruit. There have long been other places where boost code used deprecated headers from the standard libraries. That's unprofessional. Sorry to rant. This is a long standing issue for me and I thought I better write this before I saw the inevitable responses from people trying to justify their bad coding. I really would have ranted then! Patrick