C++ Nifty Counter 成语；为什么？

Question

我最近遇到了 Nifty Counter Idiom .我的理解是，这是用于在标准库中实现全局变量，如 cout、cerr 等。既然专家选择了它，我认为这是一项非常强大的技术。

我试图了解与使用更像 Meyer Singleton 的东西相比的优势。

例如，可以在头文件中包含:

inline Stream& getStream() { static Stream s; return s; }
static Stream& stream = getStream();

优点是您不必担心引用计数、新放置或有两个类，即代码更简单。既然不是这样做的，我敢肯定是有原因的:

1. 这不能保证在共享库和静态库中拥有一个全局对象吗？ ODR 似乎应该保证只能有一个静态变量。
2. 是否存在某种性能成本？在我的代码和 Nifty Counter 中，您似乎都在遵循一个引用来访问该对象。
3. 在某些情况下引用计数实际上是有用的吗？如果包含 header ，它似乎仍然会导致对象被构造，并在程序结束时被销毁，就像 Meyer Singleton 一样。
4. 答案是否涉及手动打开某些内容？我对此没有太多经验。

编辑:在阅读 Yakk 的答案时，系统提示我编写以下代码，我将其添加到原始问题中作为快速演示。这是一个非常简单的例子，展示了如何使用 Meyer Singleton + 全局引用导致在 main 之前进行初始化:http://coliru.stacked-crooked.com/a/a7f0c8f33ba42b7f .

Answer 1

静态本地/Meyer 的单例 + 静态全局引用(您的解决方案)几乎等同于漂亮的计数器。

区别如下:

1. 您的解决方案中不需要 .cpp 文件。

2. 从技术上讲，static Steam& 存在于每个编译单元中；被引用的对象没有。由于在当前版本的 C++ 中无法检测到这一点，因此在这似乎消失了。但有些实现实际上可能会创建该引用而不是删除它。

3. 有人可以在创建static Stream&之前调用getStream()；这将导致销毁顺序困难(流被销毁的时间比预期的要晚)。这可以通过违反规则来避免。

4. 该标准要求在 inline getStream 线程中创建本地 static Stream 是安全的。检测到这不会发生对编译器来说是一个挑战，因此您的解决方案中可能存在一些冗余的线程安全开销。漂亮的计数器确实不明确支持线程安全；这被认为是安全的，因为它在预期线程之前的静态初始化时间运行。

5. 对 getStream() 的调用必须发生在每个编译单元中。只有证明它不能做任何事情才能优化出来，这是困难的。漂亮的计数器具有相似的成本，但操作可能会或可能不会更简单地优化或运行时成本。 (确定这一点需要在各种编译器上检查生成的程序集输出)

6. 在 C++11 中引入的“magic statics”(没有竞争条件的静态局部变量)。在 C++11 魔术静态之前，您的代码可能存在其他问题；我能想到的唯一一个是在静态初始化期间直接在另一个线程中调用 getStream() 的人，通常应该禁止(如上所述)。

7. 在标准范围之外，您的版本会自动神奇地在每个动态链接的代码块(DLL、.so 等)中创建一个新的单例。漂亮的计数器只会在 cpp 文件中创建单例。这可能会让库编写者更严格地控​​制意外产生新的单例；他们可以将其粘贴到动态库中，而不是产生重复项。

避免拥有多个单例有时很重要。