Boost warning philosophy

From: Scott Johnson (engineerscotty_at_[hidden])
Date: 2022-08-30 02:58:44

Hello,

We are migrating a legacy codebase (embedded system though a PC
architecture) from Centos 7.x, using various boost 1.5x components and
GCC 7.3, to Ubuntu 22.04 and GCC 11.2 (the compiler that ships with
this version of Ubuntu).  As our application needs things that don't
come with the "stock" Boost version that Canonical packages for 22.04,
specifically Python 2.x support, I have downloaded and configured
Boost 1.80 for our application to use.

Unfortunately, our code development standard is -Wall -Werror (turn on
all warnings and treat them as errors), with exceptions to -Wall only
allowed grudgingly.  And this version of Boost seems to break things,
with all sorts of warnings being thrown that we simply don't see on
the older version, distro, and toolchain.  One of the biggest
offenders seems to be things like #if _MSC_VER when this preprocessor
symbol is not defined--GCC likes to warn that the symbol is being
"defaulted" to zero in this context.  (Defining it as 0 causes all
heck to break loose, as there is also plenty of #ifdef _MSC_VER in the
code).  I've also seen warnings for overloaded virtual functions being
hidden (a warning I would prefer not to disable), null pointer
dereferences (ditto), and local variables being shadowed (ditto) from
various Boost components.

This is on production builds with -O2 optimization level.

What is, if anything, the Boost policy towards compiler diagnostics of
this sort?  Is there a set of warnings we should be prepared to ignore
if we use Boost with a more modern (and pickier) compiler?  Should we
perhaps consider another version of GCC?   An older, more mature
version of Boost (we don't need any specific features in the current
one)?

Thanks,

Scott

-- 
engineer_scotty (no, not that one)
If life gives you lemons, drink Hefeweizen