静态常量与重复调用函数中的常量

Question

我只是想知道

void test()
{
   const static int ABC = 12;
   cout << ABC;
}

有什么不同

void test()
{
   const int ABC = 12;
   cout << ABC;
}

如果在程序执行时重复调用此函数 ？我的意思是，有性能差异吗？或者有什么理由让你更喜欢其中一种而不是另一种？

Answer 1

有几个因素会影响答案：

• 首先，只要该值为 const，在任何情况下都几乎肯定会被优化掉。这意味着生成的代码很可能是相同的。
• 其次，静态成员存储在其他地方，这意味着局部性较小，并且可能会出现缓存未命中的情况。
• 第三，初始化的成本取决于类型。就您而言，对于 int 来说，初始化的成本基本上不存在。对于更复杂的用户定义类型，它可能会很大。

所以答案是，在足够简单的情况下，编译器可以计算出它们并进行优化，这使得差异为零。在你的例子中几乎肯定是这种情况。

只要变量具有易于构造且成本低廉的类型，请选择非静态以避免缓存未命中。

如果构造该类型的成本很高，您可能希望使用static。

当然，最后也是最重要的一点是：

不要相信我们的猜测。如果您担心性能，那么只有一个正确的做法：

• 对其进行测量，以验证它确实是一个问题
• 测量每个可能的解决方案的性能
• 选择能带来最佳性能的解决方案。

Answer 2

理论上来说，前一种方法要好一点，因为它只实例化变量一次。

然而，编译器将简单地删除“const”行并替换为“cout << 12;”进入函数（显然，当在优化的情况下编译时）。

Answer 3

在第一次转换中，ABC 将仅在第一次函数调用时初始化一次。在第二种情况下，ABC 每次都会被初始化。如果 ABC 是带有构造函数的复杂类型，您会感觉到不同。它可以分配内存或初始化一些互斥体。对于 int 来说，实践中没有区别。

根据 C++03 标准 3.7.1/2：

如果静态存储持续时间的对象具有初始化或具有副作用的析构函数，则即使它看起来未使用，也不应将其消除，除非可以按照中的规定消除类对象或其副本
12.8。

Answer 4

这取决于编译器。

在嵌入式软件中，静态常量通常存储在闪存（即代码存储器）中，并且可以像普通变量一样直接访问，而不需要初始化。

相反，非静态 const 可能将其值存储在闪存中，但 const 本身将像变量一样在堆栈上创建，并像变量一样进行初始化。

如果这就是您的编译器处理这些情况的方式，那么 static const 会更有效，因为它既不需要堆栈分配也不需要初始化。

显然，非嵌入式编译器可能会以不同的方式处理这些场景。

Answer 5

您还可以通过使用编译器的汇编器或类似以下在线实用程序来很好地了解编译器将执行的操作：https:// /godbolt.org 并查看生成的汇编代码。

这值得一看，因为这个问题很根本。

基于您的问题的示例，考虑本地与静态类型声明和实例化，查看基元与“复杂”（甚至不是非常）：

#include <iostream>

struct non_primitive
{
    int v;
    non_primitive(const int v_) : v(v_) {}
};

void test_non_static_const_primitive()
{
   const int ABC = 12;
   std::cout << ABC;
}

void test_static_const_primitive()
{
   const static int ABC = 12;
   std::cout << ABC;
}

void test_non_static_constant_non_primitive_global_struct() 
{
    const non_primitive s(12);
    std::cout << s.v;
}

void test_non_static_constant_non_primitive_local_struct() 
{
    struct local_non_primitive
    {
        int v;
        local_non_primitive(const int v_) : v(v_) {}
    };
    const local_non_primitive s(12);
    std::cout << s.v;
}

void test_static_constant_non_primitive_global_struct() 
{
    const static non_primitive s(12);
    std::cout << s.v;
}

void test_static_constant_non_primitive_local_struct() 
{
    struct local_non_primitive
    {
        int v;
        local_non_primitive(const int v_) : v(v_) {}
    };
    const static local_non_primitive s(12);
    std::cout << s.v;
}

编译器认识到它不必处理本地 const 复杂类型的任何内存链接，并且前四种情况的处理方式相同。看起来编译器并没有尝试探索复杂类型的相对简单性以及静态实例化中进一步简化的潜力。

由此产生的成本差异是比较巨大的。

使用gcc7.2和-O3优化编译的汇编代码：

test_non_static_const_primitive():
  mov esi, 12
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
test_static_const_primitive():
  mov esi, 12
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
test_non_static_constant_non_primitive_global_struct():
  mov esi, 12
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
test_non_static_constant_non_primitive_local_struct():
  mov esi, 12
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
test_static_constant_non_primitive_global_struct():
  movzx eax, BYTE PTR guard variable for test_static_constant_non_primitive_global_struct()::s[rip]
  test al, al
  je .L7
  mov esi, DWORD PTR test_static_constant_non_primitive_global_struct()::s[rip]
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
.L7:
  sub rsp, 8
  mov edi, OFFSET FLAT:guard variable for test_static_constant_non_primitive_global_struct()::s
  call __cxa_guard_acquire
  test eax, eax
  mov esi, DWORD PTR test_static_constant_non_primitive_global_struct()::s[rip]
  je .L8
  mov edi, OFFSET FLAT:guard variable for test_static_constant_non_primitive_global_struct()::s
  mov DWORD PTR test_static_constant_non_primitive_global_struct()::s[rip], 12
  call __cxa_guard_release
  mov esi, 12
.L8:
  mov edi, OFFSET FLAT:std::cout
  add rsp, 8
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
test_static_constant_non_primitive_local_struct():
  movzx eax, BYTE PTR guard variable for test_static_constant_non_primitive_local_struct()::s[rip]
  test al, al
  je .L14
  mov esi, DWORD PTR test_static_constant_non_primitive_local_struct()::s[rip]
  mov edi, OFFSET FLAT:std::cout
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
.L14:
  sub rsp, 8
  mov edi, OFFSET FLAT:guard variable for test_static_constant_non_primitive_local_struct()::s
  call __cxa_guard_acquire
  test eax, eax
  mov esi, DWORD PTR test_static_constant_non_primitive_local_struct()::s[rip]
  je .L15
  mov edi, OFFSET FLAT:guard variable for test_static_constant_non_primitive_local_struct()::s
  mov DWORD PTR test_static_constant_non_primitive_local_struct()::s[rip], 12
  call __cxa_guard_release
  mov esi, 12
.L15:
  mov edi, OFFSET FLAT:std::cout
  add rsp, 8
  jmp std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
_GLOBAL__sub_I__Z31test_non_static_const_primitivev:
  sub rsp, 8
  mov edi, OFFSET FLAT:std::__ioinit
  call std::ios_base::Init::Init()
  mov edx, OFFSET FLAT:__dso_handle
  mov esi, OFFSET FLAT:std::__ioinit
  mov edi, OFFSET FLAT:std::ios_base::Init::~Init()
  add rsp, 8
  jmp __cxa_atexit

Answer 6

对于基本类型，例如整数值，那么我会将静态的使用作为“过早的优化”，除非您已经做了一些基准测试并考虑了各种权衡（例如将静态初始化为非静态）零值通常需要表中的一个条目来指定加载代码时要设置的位置、大小和初始值）。

除非您使用指向 int 的指针并且在函数返回后取消引用它，否则您不需要 static - 让编译器进行优化。

如果在函数退出后取消引用指向该值的指针，那么我会将其归类为持久状态变量，并且最好在类或模块级别定义它以明确这一点。

Answer 7

我会选择第二个——它更具可读性。为什么不必要地添加一个关键字（静态），它实际上不会给阅读代码的人增加任何价值。

Answer 8

static const 示例当然可以节省后续调用的执行时间，对于使用 static const 的复杂对象构造来说，速度要快得多，但我质疑是否需要将 ABC 限制在函数范围内，并引入从第一次调用到后续调用的函数行为变化来电。通常一个文件包含耦合的功能耦合函数，只需给出 ABC 文件范围并使用它即可。