From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-08-30 07:05:27
Scott Johnson wrote:
> 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
> 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
> This is on production builds with -O2 optimization level.
> What is, if anything, the Boost policy towards compiler diagnostics of this sort?
There is no overarching Boost policy on warnings; you need to submit issues
against the offending libraries.
For #if _MSC_VER, that's almost always something that needs to be fixed, but
at the same time, I don't think this warning (-Wundef) is on by default, so it's
usually not being tested. Ditto for -Wshadow - also off by default (not in -Wall).
Also, it's not always the case that a newer compiler would emit more warnings.
Newer compilers introduce new warnings, but sometimes tone down
Maybe you can post some specific examples that we can discuss.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk