[boost] (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