如何解决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(...)
以便能够不断初始化静态存储持续时间变量。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。