将静态变量声明为函数/成员函数是一种不好的做法

void SomeClass::function()
{
    static bool init = false;
    if (!init)
    {
        // hundreds of lines of ugly code
    }
    init = true;
}

这至少在高质量的代码中是很少发生的，因为它只适用于少数情况。这基本上是对全局状态进行及时初始化(以提供一些全局功能)。这方面的一个典型例子是拥有一个随机数生成器函数，该函数在第一次调用它时为生成器提供种子。它的另一个典型用法是返回单例实例的函数，该实例在第一次调用时初始化。但是其他的用例却很少。

一般来说，全局状态是不可取的，拥有包含自给自足状态的对象是首选(为了模块化等)。但是如果您需要全局状态(有时确实需要)，则必须以某种方式实现它。如果您需要任何一种重要的全局状态，那么您可能应该使用单例类，而交付应用程序范围内的单实例的首选方法之一是通过一个函数，该函数提供对在第一次调用时初始化的本地静态实例的引用。如果所需的全局状态比较琐碎，那么使用本地静态bool标志来执行该方案当然是一种可接受的方法。换句话说，我认为使用方法没有根本问题，但是如果用这样的代码呈现，我自然会质疑它的动机(需要全局状态)。

对于全局数据来说，多线程总是会导致像这样的简单实现出现一些问题。简单地引入全局状态永远不会是线程安全的，这种情况也不例外，您必须采取措施来解决特定的问题。这就是全球国家不可取的部分原因。

静态bool init到someeclass::函数的行为可以通过一个非静态成员变量来实现。

如果有实现相同行为的替代方案，则必须根据技术问题(如线程安全)对这两个替代方案进行判断。但是在这种情况下，所需的行为是有问题的，比实现细节更有问题，并且存在替代实现并没有改变这一点。

第二，我不知道如何用基于非静态数据成员(可能是静态数据成员)的任何东西来替换全局状态的即时初始化。即使可以，它也会很浪费(对于每个程序执行一次的事情需要每个对象存储)，并且仅从这一点来看，它不会是一个更好的选择。

someeclass中的其他函数无法检查静态bool初始值，因为它的可见性仅限于void someeclass::function()范围。

我通常会把它放在"赞成"一栏(如赞成/反对)。这是一件好事。这就是信息隐藏或封装。如果你能把别人不应该关心的事情藏起来，那就太好了!但是，如果有其他函数需要知道全局状态是否已经初始化，那么您可能需要更类似于单例类的东西。

静态变量不是oop，因为它们定义的是全局状态而不是对象状态。

不管你喜不喜欢，谁在乎呢?但是，是的，全球状态是这里关注的问题。而不是使用局部静态变量来实现其初始化。全局状态，尤其是可变的全局状态，通常是不好的，不应该被滥用。它们阻碍了模块化(如果依赖全局状态，模块就不那么自给自足)，它们引入了多线程问题，因为它们本质上是共享数据，它们使任何使用它们的函数不可重入(非纯)，它们使调试变得困难，等等……这样的例子不胜枚举。但这些问题大多与你如何实现它无关。另一方面，使用局部静态变量是解决static-initialization-order-惨败的好方法，因此，它们是好的，在向代码中引入(合理的)全局状态时，可以少担心一个问题。

考虑多线程。当function()可以被多个线程并发调用时，这种类型的代码是有问题的。没有锁，就会出现竞争条件;使用锁，并发性可能会受到损害，而没有实际的好处。

全局状态可能是这里最严重的问题。其他函数不需要关心它，所以这不是问题。事实上，没有static变量也可以实现，这实际上意味着您创建了某种形式的单例。这当然会带来单例模式的所有问题，比如完全不适合多线程环境。

加上其他人所说的，您不能同时拥有该类的多个对象，或者至少它们不会像预期的那样运行。第一个实例将设置静态变量并进行初始化。后来创建的实例虽然没有自己的init版本，但与所有其他实例共享它。由于第一个实例将其设置为true，因此下面的所有内容都不会进行任何初始化，这很可能不是您想要的。