Warnings present a difficult conundrum for Boost. I wonder if there's any way we can come up with a coherent policy, so individual library developers don't have to think through all the issues individually and our users develop consistent expectations. Here's what I know: * Some warnings that are just a nuisance, especially for templated code. For example, I am getting a warning from vc-8 that the implicit assignment operator of a particular class template instantiation couldn't be generated. I expect the availability of implicit assignment in that case to depend on the template parameter. In this case, any class template that can take reference arguments that become members of the class is susceptible. * It's impolite to unconditionally disable warnings that people may count on in their own code. The above is a nuisance for me, but it might be crucial for someone developing ordinary classes. * Some popular compilers (GCC) don't have #pragmas that let us turn off warnings in particular regions of code. On those compilers, there is sometimes no workaround in code; suppressing the warning must be done on the compiler's command-line. We can do it in Boost.Build, but of course that won't help people who are using other build systems. And for those that _are_ using Boost.Build, suppressing warnings at that point can be just as impolite as doing it in code. * Even when in-code workarounds are possible, they're often ugly, and since the workarounds (e.g. #pragmas) can be different for every compiler, they really pile up. So, ideas, anyone? -- Dave Abrahams Boost Consulting www.boost-consulting.com