来自 boost 的警告

Question

我收到很多来自 boost 库标头的警告，有什么方法可以解决这个问题吗？

libs/boost/include/boost/numeric/ublas/detail/vector_assign.hpp:382:39: warning: typedef ‘reference’ locally defined but not used [-Wunused-local-typedefs]
         typedef typename V::reference reference;

libs/boost/include/boost/numeric/ublas/detail/vector_assign.hpp:516:40: warning: typedef ‘value_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef typename V::value_type value_type;

libs/boost/include/boost/numeric/ublas/detail/matrix_assign.hpp:644:40: warning: typedef ‘value_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef typename M::value_type value_type;

libs/boost/include/boost/numeric/ublas/operation.hpp:132:26: warning: typedef ‘expression2_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef const E2 expression2_type;

libs/boost/include/boost/numeric/ublas/operation.hpp:191:26: warning: typedef ‘expression1_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef const E1 expression1_type;

libs/boost/include/boost/numeric/ublas/operation.hpp:193:39: warning: typedef ‘size_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef typename V::size_type size_type;

如果这很重要我的

gcc --version

gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

更新：

类似问题的解决方案看起来很合理：https://stackoverflow.com/a/1900578/1179925

Answer 1

主要问题是来自第三方或系统头文件的（很多）警告（大多数时候）可以安全地忽略。我的解决方案是将我的源文件命名为

*.cpp

和

*.hpp

并添加额外的头文件

*.cpp.h

和

*.hpp.h

以包含警告生成头文件，如下所示：

#pragma once

#if defined __GNUC__
#   pragma GCC system_header
#elif defined __SUNPRO_CC
#   pragma disable_warn
#elif defined _MSC_VER
//# pragma warning(push, 0)
#   pragma warning(push)
#   pragma warning(disable : 4800)
//# pragma warning(disable : ...)
#endif

// BEGIN INCLUDING 3RD PARTY HEADERS
#include <QApplication>
#include <QTextCodec>
#include <QTranslator>
#include <QLocale>
//#include <boost/someboostheader.hpp>
// END INCLUDING 3RD PARTY HEADERS

#if defined __SUNPRO_CC
#   pragma enable_warn
#elif defined _MSC_VER
#   pragma warning(pop)
#endif

这至少应该适用于 GCC 和 Visual Studio，因为我从未测试过 Sun C++ 编译器。

对于 Visual Studio，警告

pragma

可以放入“正常”头文件和源文件中，但对于 GCC 则不起作用。对于 GCC，行

pragma GCC system_header

声明整个头文件为系统头文件，其中警告将被忽略。当然，这不是系统头文件，但它应该只包含那些 boost 头文件。

当然：向您的解决方案添加更多头文件远不是一个优雅的解决方案。但它有效。

Answer 2

根据我的经验，警告永远不应该被“安全地忽略”。这样做的原因并不是说它们一定会破坏任何东西，尽管它们肯定可以，否则编译器为什么会发出警告？但是，当我们养成忽略编译器警告的习惯时，我们就会变得自满。然后，当屏幕上飞过一条很可能很重要的警告时，我们就会忽略它，然后它就会回来咬我们。当必须修复它的人看到发出警告时，他正确地问 WTF 是在思考中检查此代码的人吗？

如果存在发出警告的代码的合理原因，例如上述未使用的 typedef，则应使用适当的标志构建具有 typedef 的代码以禁用警告，或者更好的是添加编译指示（如果存在）带有注释，仅围绕需要它的代码，以便编译器对其余代码的检查不会关闭。或者更好的是，避免添加不在任何地方使用的 typedef。重点是什么？需要时添加它们。关键是，如果出现编译器警告，则应该：1）修复； 2) 如果可能的话，在代码中使用编译指示禁用； 3) 使用文件的编译器标志进行修复； 4）不要被忽视...

当代码被维护得能够干净地编译时，就会出现明显的警告，并向开发人员尖叫“立即修复我”！我知道我不想成为第一个引入发出警告的代码的人，而其他一切都构建得很干净。

这只是我过去 4 年来工作过的任何团队的做法，我们永远不会检查任何不干净地构建在 all 支持的代码上平台。真的没有理由做其他事情，这只是懒惰和不好的做法。 所以，当我编译像 Boost 这样的东西时，我看到一页又一页的编译器警告，我不得不想知道谁在维护这个软件，以及什么样的讨厌的小鼻屎正等着咬我的屁股。 .