c++ - 全局对象和创建顺序

Question

我还在学习 C++。我有一个问题。假设您的项目具有始终存在的全局对象，例如 ApiManager 并且所有其他模块都可以访问它(通过 #include)。现在我正在通过:

标题:

class ApiManager : public QObject
{
    Q_OBJECT
public:
    explicit ApiManager(QObject *parent = 0);
signals:
public slots:
};

extern ApiManager apiMng;

来源:

ApiManager apiMng;

问题是其他对象在初始化时也需要访问，我注意到 C++ 全局对象是按字母顺序创建的。我想知道你是如何处理的？存在一些技巧吗？例如，在 Free Pascal 世界中，每个类模块都有 initialization 和 finalization 部分:

Type
  TApiManager = class
end;

var ApiMng: TApiManager;

initialization
  ApiMng := TApiManager.Create;
finalization
  ApiMng.Free;

...和initialization 项目模块的顺序可以在uses 子句中的项目源中排序(如C++ 中的#include)。我知道有很多方法可以做到这一点(例如使用自定义顺序初始化 main.cpp 中的所有内容)但想知道什么是 C++ 世界中的“好习惯”

编辑:由 Q_GLOBAL_STATIC 解决(在 Qt 5.1 中引入，但也适用于 Qt 4.8)但仍有两个问题:

1. 仍然不知道如何管理构造函数顺序(以及在哪里初始化它)。因为 Q_GLOBAL_STATIC 创建的全局对象不是在应用程序启动时创建的。它们是在第一次使用时创建的。所以我需要用我的自定义顺序在某处(在 main.cpp 中？)“触摸”这些对象。

2. 文档说 Q_GLOBAL_STATIC 必须在正文 .cpp 文件中调用，而不是在 header 中调用。但是其他类看不到这个对象。所以我创建了公开对此对象的引用的静态函数:

.cpp:

Q_GLOBAL_STATIC(ApiManager, apiMng)
ApiManager *ApiManager::instance()
{
    return apiMng();
}

但是从这个主题:http://qt-project.org/forums/viewthread/13977 Q_GLOBAL_STATIC 应该自动公开实例，但它没有

Answer 1

它们不是按字母顺序初始化的，并且翻译单元之间的初始化顺序是未定义的，因为标准对此没有任何保证。

Why global variables are evil

Global variables should be avoided for several reasons, but the primary reason is because they increase your program’s complexity immensely. For example, say you were examining a program and you wanted to know what a variable named g_nValue was used for. Because g_nValue is a global, and globals can be used anywhere in the entire program, you’d have to examine every single line of every single file! In a computer program with hundreds of files and millions of lines of code, you can imagine how long this would take!

Second, global variables are dangerous because their values can be changed by any function that is called, and there is no easy way for the programmer to know that this will happen.

Why Global Variables Should Be Avoided When Unnecessary

Non-locality -- Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.

No Access Control or Constraint Checking -- A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.) By extension, the lack of access control greatly hinders achieving security in situations where you may wish to run untrusted code (such as working with 3rd party plugins). Implicit coupling -- A program with many global variables often has tight couplings between some of those variables, and couplings between variables and functions. Grouping coupled items into cohesive units usually leads to better programs.

Concurrency issues -- if globals can be accessed by multiple threads of execution, synchronization is necessary (and too-often neglected). When dynamically linking modules with globals, the composed system might not be thread-safe even if the two independent modules tested in dozens of different contexts were safe.

Namespace pollution -- Global names are available everywhere. You may unknowingly end up using a global when you think you are using a local (by misspelling or forgetting to declare the local) or vice versa. Also, if you ever have to link together modules that have the same global variable names, if you are lucky, you will get linking errors. If you are unlucky, the linker will simply treat all uses of the same name as the same object. Memory allocation issues -- Some environments have memory allocation schemes that make allocation of globals tricky. This is especially true in languages where "constructors" have side-effects other than allocation (because, in that case, you can express unsafe situations where two globals mutually depend on one another). Also, when dynamically linking modules, it can be unclear whether different libraries have their own instances of globals or whether the globals are shared.

Testing and Confinement - source that utilizes globals is somewhat more difficult to test because one cannot readily set up a 'clean' environment between runs. More generally, source that utilizes global services of any sort (e.g. reading and writing files or databases) that aren't explicitly provided to that source is difficult to test for the same reason. For communicating systems, the ability to test system invariants may require running more than one 'copy' of a system simultaneously, which is greatly hindered by any use of shared services - including global memory - that are not provided for sharing as part of the test.

一般来说，请根据经验避免使用全局变量。如果您确实需要它们，请使用 Q_GLOBAL_STATIC .

Creates a global and static object of type QGlobalStatic, of name VariableName and that behaves as a pointer to Type. The object created by Q_GLOBAL_STATIC initializes itself on the first use, which means that it will not increase the application or the library's load time. Additionally, the object is initialized in a thread-safe manner on all platforms.

您还可以使用 Q_GLOBAL_STATIC_WITH_ARGS .在这里您可以从文档中找到一些内联亮点:

Creates a global and static object of type QGlobalStatic, of name VariableName, initialized by the arguments Arguments and that behaves as a pointer to Type. The object created by Q_GLOBAL_STATIC_WITH_ARGS initializes itself on the first use, which means that it will not increase the application or the library's load time. Additionally, the object is initialized in a thread-safe manner on all platforms.

有些人也倾向于创建一个函数来包装它们，但他们并没有显着降低复杂性，他们最终要么忘记使这些函数成为线程安全的，要么他们加入了更多的复杂性。也忘记这样做什么时候可以。