我真的需要大量使用explicit关键字吗？

Question

当我使用最近发布的Cppcheck 1.69对我的代码¹进行检查时，它显示了许多我原本不希望出现的消息。禁用noExplicitConstructor后，发现所有这些消息都是相同类型的。

但我发现，我不是唯一一个收到许多新Cppcheck消息的人，请看LibreOffice分析结果（我被允许公开显示）：

有经验的程序员会怎么做：

• 抑制检查？
• 大规模引入explicit关键字？

---

¹当然，这不是我的代码，而是我在工作中必须处理的代码，它是遗留代码：混合了C和C++，使用了几种（之前的）标准版本（比如说C++98），并且是一个相当庞大的代码库。

- Wolf

---

一个有经验的程序员会在必要时使用 explicit，并在需要隐式转换时省略它。 - juanchopanza

我不能代表其他程序员（有经验或没有经验）说话，但是我会使用“explicit”除非我特别想要允许隐式转换。这可以减少出现意外情况的可能性。 - Mike Seymour

cppcheck只是一种高级模式匹配工具。它既不智能也不权威，也不知道你的意图。你应该把它的输出仅仅当作需要修复的某些东西的提示。如果输出中有几千个或多或少相同的条目，通常可以安全地忽略它们，因为这是“过于热心”的表现。我编写了一些程序，在cppcheck中生成了成千上万个错误警告（其中没有一个需要修复）。 - Damon

引入显式语法的反对意见有哪些？(a) 涉及多个文件，可能会出现编辑错误；(b) 修改多个文件会在不同版本间造成干扰；(c) 投入时间和精力可能更有效地用于针对性调试。 - Peter - Reinstate Monica

不，不一定。我只是试图考虑一些事情。可以通过以下方法减轻修订差异的“噪音”：(1)对当前版本运行所有测试;(2)仅执行“显式”更改，并再次运行测试，希望注意到任何运行时更改，如新的或消失的错误;并使用该结果修订作为真正实质性更改的定义基础。即，不要按文件逐个处理，并将其与其他错误修复混合。(我认为 OpenSSL 就走了这条路，参见 https://www.openssl.org/blog/blog/2015/01/05/source-code-reformat/。) - Peter - Reinstate Monica

Answer 1

我过去因为隐式转换带来的性能损失和纯粹的错误而受到了打击。因此，我倾向于对所有不想参与隐式转换的构造函数都使用explicit关键字，以便编译器可以帮助我捕获错误-然后我还尝试在那些我明确希望它们被用作隐式转换构造函数的构造函数中添加“// implicit intended”注释。我发现这有助于我编写更正确、更少出乎意料的代码。

所以我会说，“是的，请加上explicit”，从长远来看，你会感到高兴的-当我第一次知道它时，我就这样做了，我很高兴自己这样做了。

- Jesper Juhl

---

感谢您查看此内容。顺便说一句：如果您只使用注释，cppcheck仍会发出警告。为了禁用其警告，我使用内联抑制，因此我有一个关于有意的隐式转换的功能性注释。（到目前为止，这是我最喜欢的答案;-)） - Wolf

这个规则的一个例外是constexpr构造函数。由于它们不会产生运行时开销，因此它们应该适用于隐式转换。 - EvertW