clang的全局构造函数是否警告过严？

问题描述

在我们的项目中，我们经常使用这样的构造（为简化起见，我们实际上使用的是更安全的版本）：

struct Info
{
    Info(int x,int y) : m_x(x),m_y(y)
    {}

    int m_x;
    int m_y;
};

struct Data
{
    static const Info M_INFO_COLLECTION[3];
};

const Info Data::M_INFO_COLLECTION[] =  // global-constructors warning
{
    Info(1,2),Info(10,9),Info(0,1)
};

M_INFO_COLLECTION可以包含大量数据点。初始化部分位于cpp文件中，该文件通常是代码生成的。

现在，此结构为我们的整个代码库提供了相当数量的global-constructors警告。我已经读过in a blog post，对于夜间构建，在-Weverything组中使用警告不是一个好主意，我同意，甚至对clang doc does not recommend to use it也是如此。

由于关闭警告的决定已无法控制，我可以使用a helpful trick来消除警告（以及潜在的静态初始化命令惨败），方法是转换为将静态成员插入函数，以初始化并返回局部静态变量。

但是，由于我们的项目通常不使用动态分配的内存，因此必须在没有指针的情况下使用原始思想，当我的Data类被其他人使用时，这可能导致deinitialization problems怪异的物体。

因此，长话短说：global-constructors警告指向一段我可以安全阅读的代码，因为我知道Data类的作用。如果 other 类以特定方式使用Data会导致问题，我可以使用一种解决方法来摆脱它，但这不会产生警告。我的结论是，最好还是保留原代码而不理会警告。

因此，我现在遇到一堆警告，在某些情况下可能会指向SIOF，并且我想解决，但是在我故意不想解决的警告中埋下了很多警告，因为该修复程序实际上会使情况变得更糟。

这使我想到了一个实际的问题：clang对警告的解释太严格了吗？从我对编译器的有限了解来看，编译器是否应该不可能意识到在这种特殊情况下，静态成员M_INFO_COLLECTION不可能导致SIOF，因为其所有依赖项都是非静态的？

我在这个问题上玩了一点，甚至这段代码也得到了警告：

//at global scope

int get1() 
{
    return 1;
}

int i = get1(); // global-constructors warning

这很好，正如我所期望的那样：

constexpr int get1() 
{
    return 1;
}

int i = 1;  // no warning
int j = get1(); // no warning

对我来说，这看起来微不足道。我是否缺少某些东西，或者clang应该能够抑制此示例的警告（可能还有我上面的原始示例）？

解决方法

问题在于它不是常量初始化的。这意味着M_INFO_COLLECTION可以初始化为零，然后在运行时动态初始化。

由于“全局构造函数”（非恒定初始化），您的代码会生成汇编来动态设置M_INFO_COLLECTION：https://godbolt.org/z/45x6q6

一个导致意外行为的示例：

// data.h
struct Info
{
    Info(int x,int y) : m_x(x),m_y(y)
    {}

    int m_x;
    int m_y;
};

struct Data
{
    static const Info M_INFO_COLLECTION[3];
};


// data.cpp
#include "data.h"

const Info Data::M_INFO_COLLECTION[] =
{
    Info(1,2),Info(10,9),Info(0,1)
};


// main.cpp
#include "data.h"

const int first = Data::M_INFO_COLLECTION[0].m_x;

int main() {
    return first;
}

现在，如果您在main.cpp之前编译data.cpp，first可能会在生命周期之外访问Info。实际上，此UB仅使first 0。

例如

$ clang++ -I. main.cpp data.cpp -o test
$ ./test ; echo $?
0
$ clang++ -I. data.cpp main.cpp -o test
$ ./test ; echo $?
1

当然，这是未定义的行为。在-O1处，此问题消失了，并且clang的行为就像M_INFO_COLLECTION被常量初始化一样（就像它将动态初始化重新排序为first的动态初始化之前一样（以及其他所有动态初始化）），这是允许的。）

此问题的解决方法是不使用全局构造函数。如果您的静态存储持续时间变量能够被常量初始化，则使相关的函数/构造函数为constexpr。

如果您无法添加constexpr或必须来使用非常量初始化变量，则可以使用placement- { {1}}：

new

尽管与常规静态存储持续时间变量相比，这确实对每次访问（尤其是第一次访问）具有较小的运行时开销。它应该比// data.h struct Info { Info(int x,m_y(y) {} int m_x; int m_y; }; struct Data { static auto M_INFO_COLLECTION() -> const Info(&)[3]; static const Info& M_ZERO(); }; // data.cpp #include "data.h" #include <new> auto Data::M_INFO_COLLECTION() -> const Info(&)[3] { // Need proxy type for array reference struct holder { const Info value[3]; }; alignas(holder) static char storage[sizeof(holder)]; static auto& data = (new (storage) holder{{ Info(1,1) }})->value; return data; } const Info& Data::M_ZERO() { // Much easier for non-array types alignas(Info) static char storage[sizeof(Info)]; static const Info& result = *new (storage) Info(0,0); return result; }技巧要快，因为它不会调用内存分配运算符。

简而言之，最好添加new T(...)以便能够不断初始化静态存储持续时间变量。

c++clang compiler-warnings