C++ 中的纯/常量函数

Question

我正在考虑在我的 C++ 代码中更多地使用纯/常量函数。 （GCC 中的 pure/const 属性）

但是，我很好奇如何我应该严格关注它以及可能发生的情况。

最明显的情况是调试输出（无论何种形式，可以在 cout 上、在某些文件中或在某些自定义调试类中）。我可能会有很多函数，尽管有这种调试输出，但它们不会产生任何副作用。无论是否进行调试输出，这绝对不会对我的应用程序的其余部分产生任何影响。

或者我想到的另一种情况是使用一些 SmartPointer 类，当处于调试模式时，它可能会在全局内存中执行一些额外的操作。如果我在纯/常量函数中使用这样的对象，它确实会产生一些轻微的副作用（从某种意义上说，某些内存可能会有所不同），但不应该有任何真正的副作用（从某种意义上说，行为是在任何不同的方式）。

互斥体和其他东西也类似。我可以想到许多复杂的情况，其中它有一些副作用（从某种意义上说，某些内存会有所不同，甚至可能创建一些线程，进行一些文件系统操作等）但没有计算差异（所有这些副作用很可能被排除在外，我什至更喜欢这样）。

因此，总而言之，我想将严格意义上不是纯/常量的函数标记为纯/常量。一个简单的例子：

int foo(int) __attribute__((const));

int bar(int x) {
   int sum = 0;
   for(int i = 0; i < 100; ++i)
       sum += foo(x);
   return sum;
}

int foo_callcounter = 0;

int main() {
   cout << "bar 42 = " << bar(42) << endl;
   cout << "foo callcounter = " << foo_callcounter << endl;
}

int foo(int x) {
   cout << "DEBUG: foo(" << x << ")" << endl;
   foo_callcounter++;
   return x; // or whatever
}

请注意，函数foo在严格意义上不是const。不过，foo_callcounter 最终是什么并不重要。是否未执行调试语句（如果未调用该函数）也无关紧要。

我期望输出：

DEBUG: foo(42)
bar 42 = 4200
foo callcounter = 1

没有优化：

DEBUG: foo(42) (100 times)
bar 42 = 4200
foo callcounter = 100

两种情况都很好，因为对我的用例来说唯一重要的是 bar(42) 的返回值。

实践中效果如何？ 如果我将此类函数标记为 pure/const，是否会破坏任何内容（考虑到代码都是正确的）？

---

请注意，我知道某些编译器可能根本不支持此属性。 （顺便说一句，我正在这里收集它们。）我也知道如何以代码保持可移植性的方式使用这些属性（通过#defines）。另外，我感兴趣的所有编译器都以某种方式支持它；所以我不关心我的代码是否在编译器上运行得更慢，而编译器则不然。

我还知道，优化后的代码可能看起来会有所不同，具体取决于编译器甚至编译器版本。

---

这篇 LWN 文章“纯函数和常量函数的含义” 也非常相关，尤其是“秘籍”章。 _{（感谢 ArtemGr 的提示。）}

Answer 1

我期望的输出：

我期望输入：

int bar(int x) {
   return foo(x) * 100;
}

你的代码对我来说实际上看起来很奇怪。作为维护者，我认为要么 foo 实际上有副作用，要么更有可能立即将其重写为上述函数。

实际效果如何？ 如果我将此类函数标记为 pure/const，是否会破坏任何内容（考虑到代码都是正确的）？

如果代码全部正确，则不会。但你的代码正确的可能性很小。如果您的代码不正确，那么此功能可以掩盖错误：

int foo(int x) {
    globalmutex.lock();
    // complicated calculation code
        return -1;
    // more complicated calculation
    globalmutex.unlock();
    return x;
}

现在给出上面的条：

int main() {
    cout << bar(-1);
}

这以 __attribute__((const)) 终止，但否则会死锁。

这也很大程度上取决于实施。例如：

void f() {
    for(;;) 
    {
        globalmutex.unlock();
        cout << foo(42) << '\n';
        globalmutex.lock();
    }
}

编译器应该将调用 foo(42) 移到哪里？是否允许优化此代码？不是一般情况下！因此，除非循环真的很微不足道，否则您的功能不会带来任何好处。但如果你的循环很简单，你可以轻松地自己优化它。

编辑：由于阿尔伯特要求一个不太明显的情况，所以它来了：
F
或者例如，如果您为 ostream 实现运算符 <<，则可以使用 ostream::sentry 来锁定流缓冲区。假设您在释放之后或锁定之前调用 pure/const f。有人使用这个运算符cout << YourType() 和 f 也使用 cout << “调试信息”。根据您的说法，编译器可以自由地将 f 的调用放入临界区。发生死锁。

Answer 2

我会检查生成的汇编，看看它们有什么区别。 （我的猜测是，从 C++ 流切换到其他流会产生更多真正的好处，请参阅：http://typethinker.blogspot.com/2010/05/are-c-iostreams-really-slow.html )

Answer 3

我认为没有人知道这一点（除了 gcc 程序员），仅仅是因为您依赖于未定义和未记录的行为，这些行为可能会因版本而异。但是像这样怎么样：

#ifdef NDEBUG \
    #define safe_pure __attribute__((pure)) \
#else \
    #define safe_pure \
#endif

我知道这并不完全是您想要的，但现在您可以使用 pure 属性而不违反规则。
如果您确实想知道答案，您可以在 gcc 论坛（邮件列表等）中询问，他们应该能够给您确切的答案。
代码含义：当定义NDEBUG（断言宏中使用的符号）时，我们不进行调试，没有副作用，可以使用纯属性。当它被定义时，我们有副作用，所以它不会使用纯属性。

Answer 4

我正在考虑在我的 C++ 代码中更多地使用纯/常量函数。

这是一个滑坡。这些属性是非标准，它们的好处主要限于微观优化。

这不是一个好的权衡。相反，编写干净的代码，不要应用此类微观优化，除非您已经仔细分析并且没有办法解决它。或者根本没有。

请注意，原则上这些属性非常好，因为它们明确为编译器和程序员声明了函数的隐含假设。这很好。然而，还有其他方法可以明确类似的假设（包括文档）。但由于这些属性是非标准的，因此它们在正常代码中没有位置。它们应该被限制在性能关键的库中非常明智地使用，在这些库中，作者试图为每个编译器生成最好的代码。也就是说，作者意识到只有 GCC 可以使用这些属性，并对其他编译器做出了不同的选择。

Answer 5

你肯定会破坏代码的可移植性。为什么你想要实现你自己的智能指针——除了学习经验之外？ （近）标准库中没有足够的可用资源吗？