c++ - 现代 C++ 与 clang-tidy 会导致相反的警告

Question

这是我的第二个问题，我试图找到匹配的请求，希望这次我没有忽略它。

我正在尝试更深入地了解现代 C++。所以一个提示是通过使用 clang 自己教它，我正在尝试 atm，但我被困住了，因为当我试图纠正它时，一个函数会导致相反的警告。

背景信息:我使用的是单例模式，它需要在源代码中的多个位置返回唯一的一个实例。这是一个简单的实现，我知道多线程程序中可能存在的问题。但这正在 build 中。 检查是通过 VSCode-1-73-1 中的 clang 内置选项 --checks=* 完成的，正如 Jason Turner 为学习现代 C++ 所建议的那样。唯一禁用的检查是 llvmlibc-*，因为它会给命名空间带来很多麻烦。

这是源代码的第一个警告<为此函数使用尾随返回类型 C/C++ (modernize-use-trailing-return-type)>:

namespace some::own::implementations {

  Example* Example::getInstance() { // <-- hint for getInstance
    static Example _instance;
    return &_instance;
  }

} //  namespace some::own::implementations

错误的解释并不难，所以我重构了它(包括我在这里跳过的 header 部分)并得到了下一个提示<此函数声明 C/C++ 不允许使用尾随返回类型(fuchsia-trailing -返回)>:

namespace some::own::implementations {

  auto Example::getInstance() -> Example* { // <-- hint for auto
    static Example _instance;
    return &_instance;
  }

} //  namespace some::own::implementations

好吧，现在我有点困惑出了什么问题？好吧，一种解释可能是第一个暗示，modernize-use-trailing-return-type 是更一般的一种，而紫红色可能是一个公司或团体的哲学，它被允许向 clang 添加规则，因为我们可以取消选择它们。

我现在想到的问题:

1. 有关现代化和紫红色的解决方案正确吗？
2. 向应该或可以教导人们实现现代 C++ 代码的正确方法的工具中添加相反的警告是否有意义？
3. 如果检查中存在不同的理念(我不知道 atm)，尝试学习现代 C++ 的人应该遵循哪些理念？
4. 该功能的正确解决方案是什么？

Answer 1

1. 你说得对，Fuchsia 是一组开发人员的意见，而 lint 检查是一组不同开发人员的意见，有时它们是不同的意见。

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/lint澄清 Fuchsia 禁用这些检查:

- clang-diagnostic-unused-command-line-argument - ninja-generated compilation database contains the linker argument, which ends up unused and triggers this warning for every file
- misc-noexcept* - Fuchsia doesn't use C++ exceptions
- misc-non-private-member-variables-in-classes - We don't allow classes/structs with a mix of private and public members, but all public is fine.
- modernize-deprecated-headers - Fuchsia uses old-style C headers
- modernize-use-nodiscard - Not generally used in the Fuchsia codebase
- modernize-raw-string-literal - the check was suggesting to convert \xFF literals, which we'd rather keep in the escaped form.
- modernize-return-braced-init-list - concerns about readability of returning braced initialization list for constructor arguments, prefer to use a constructor explicitly
- modernize-use-emplace - enabled the IgnoreImplicitConstructors option to comply with Abseil Tip of the Week #112.
- modernize-use-equals-delete - flagging all gtest TEST_F
- modernize-use-trailing-return-type - Fuchsia C++ code typically uses the int foo() style of defining functions, and not the auto foo() -> int style as recommended by this check.
- readability-implicit-bool-conversion - Fuchsia C++ code commonly uses implicit bool cast of pointers and numbers
- readability-isolate-declaration - Zircon code commonly uses paired declarations.
- readability-uppercase-literal-suffix - Fuchsia C++ code chooses not to impose a style on this.

通常人们会启用他们同意的检查。预计不会有人启用所有检查。

确实存在不同的哲学。您应该关注您最同意的一个。

两者都不对。他们都是意见。