(Nuisance) Warnings

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-21 10:27:29

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