この記事では、’global’というのは、以下のようなオブジェクトを意味する：

• 静的記憶期間をもつnamespace-scope オブジェクト(namespaceは global でも無名でも可)
• スレッド記憶期を持つnamespace-scope オブジェクト
• クラスのstaticデータメンバ
• ‘global’ への参照

globalの利用はいろいろな意味で問題になる。コードの局所性を破壊するので、しばしばプログラムの理解の妨げになる。関数呼び出しがglobalを変更しているかどうか分からない。globalへのアクセスは、ロック機構でglobalを保護するか、atomicを使わない限りデータレースを引きおこしやすい。C++は’動的ライブラリ’の概念がないので、プログラムがあるライブラリに動的にリンクしたとき、globalがどう振る舞うべきか規定されていない。いずれかがglobalのコピーを持つべきか？globalはライブラリがリンクされる前に初期化されるべきか？しかしライブラリがリンクするまえに動的ライブラリのglobalを初期化できるわけがない… あとglobalは作成される前にも、破棄した後にもアクセスしたり使ったりできてしまう。

ここで示したいのは、globalの初期化の順の問題についてである。次のような二つのファイルにまたがる例を考えてみよう：

file 1:

1   extern std::mutex m; // declaration
2   std::thread t1{job1};
3   std::thread t2{job2};
4   //...

file 2:

1   std::mutex m; // definition
2     
3     
4   // ...

mutex mのようなシチュエーションは実際のプログラムでもよく見られる。すなわち、ヘッダファイルに宣言があり、実際のglobalオブジェクトは別のファイルに定義されている、というケースだ。さて、mainが実行される前にふたつのスレッドがふたつのジョブにとりかかる。mainが走る前にジョブの一部が実行される。このふたつのスレッドはmutex mで同期を取らなければならない。mutexで同期を取るにはロックされているかどうか確認して(値を読み取り)、ロックする(そして値を書き込む)。しかし、最初のスレッドが初めてmutexでロックしようとしたとき、はたしてmutexはデフォルトコンストラクタで初期化されているだろうか？

お気づきのことかもしれないが、この問題は「静的オブジェクトの初期化順の問題(static initialization order fiasco)」と呼ばれる。すなわち、mがglobalとしてある翻訳単位(ファイル)にあり、t1とt2がglobalとして別の翻訳単位にあるとき、異なる翻訳単位にあるglobal間の初期化順は一般に決定不能である…。

さてここで’一般に’というワードを強調しておく。というのはC++11はC++03よりはるかに、これが問題になるケースが少ないからで、実際のところ、上記の例は静的初期化と呼ばれる機能により初期化順の問題が解決される。

概してその機構は次のように説明される。型のコンストラクタがある制約を満たしており、コンストラクタに渡される実引数がある制約を満たしているとき、globalはプログラムが実際に実行されるまえ、すなわちコンパイル時に初期化されることが保証される。この機構はまったく新しいものではなく、制限つきながらC++03にもzero-initializationとして存在している。

例えばintやfloat、pointerやその配列などのように、トリビアルなデフォルトコンストラクタを持ち、明示的な初期化子を持たない型のglobalは、コンパイル時に0で初期化される。コンパイル時にグローバルアドレスに配置されているglobalについては簡単に達成され(スレッドロゥカルなオブジェクトに関してはこの限りではないが)、また0埋めするのはコンパイラに負荷をかけない。これは実行時にアロケートされ、0埋めするために実行時オーバーヘッドがかかるる自動オブジェクトと違う点である。

globalのZero-initializationは種々の有用なデザインに適用できる。例えば、なにも初期化しなくてもglobal intを宣言するだけでカウンタを作ることができる。

1   int counter; // no initializer

これは0クリアが保証されている。同様に、次のように生ポインタの遅延ロードを実装することもできる。

1   Utility * ptr; // no initializer
2    
3   Utility & getUtility()
4   {
5     if (!ptr) {
6       ptr = new Utility;
7     }
8     return *ptr;
9   }

これも、null-pointerで初期化されていることが保証されている。しかしながら、(並行処理の問題はいったん置くとしても)、この例には問題がある。ロードしたオブジェクトを破棄する必要性が生じたとき、まずsmart pointerを使うことを考えるだろうが、smart pointerは’プリミティヴ’ではないし、自前のデフォルトコンストラクタを持っている(か、デフォルトコンストラクタ自体ない)場合がほとんどだろう。zero-initializationの保証は失われてしまう。

ゆえに、読者はGo言語で薦められている初期化アプローチを適用してみようと考えるかもしれない。 すなわち、型のデータを工夫して、zero-initializationが自前の型について有効になるようにするのである。ポインタについては簡単だ。

1   template <class T>
2   class SmartPointer
3   {
4     T * rawPtr_;
5     // no constructor
6   };

zero-initializationはこのオブジェクトについて有効になり、nullの生ポインタを保持するnull smart pointerができる。mutexの場合は、このアプローチは実装に制限ができる。mutexの実装は次のようになるだろう：

1   class mutex
2   {
3     bool youCanLockMe_;
4     vector<thread::id> threadsLocked_;
5     // invariant: if (youCanLockMe_) threadsLocked_.empty();
6   };

ここで、youCanLockMe_ はどのスレッドもmutexをロックしていないことを示し、threadsLocked_は現在ロックされているthreadのリストであり、現在のオーナーがロックが解除した時通知を行う。この実装はzero-initializationでは二つの理由で動作しない。まず、youCanLockMe_フラグはzero-initializationの結果falseに設定されるので、mutexはロック状態で初期化されることになり、どうやってもアンロックできないことになってしまう。次に、vectorはzero-initializationのタイミングでは利用できない。すなわち、デフォルトコンストラクタ(実行時にのみ呼ばれる)は、vectorにアクセスする前に呼び出されなければならない。さもなければ未定義動作になってしまう。

一方、以下のような実装ならば動作する。

01  class treadIdLink
02  {
03    thread::id id_;
04    SmartPointer<treadIdLink> next_;
05  };
06   
07  class mutex
08  {
09    bool locked_;
10    SmartPointer<treadIdLink> threadsLocked_;
11    // invariant: if (!locked_) threadsLocked_ == nullptr;
12  };

まずここでは、フラグの意味を逆にしたので、zero-initializationの結果、フラグは今mutexをロック可能であることを示している。また、ロックしたスレッドのリストをlinked listに保持している。こうすれば、smart pointerをzero-initializationした結果であるnull-pointerで空のリストを表現できる(うまくいけば)。

この方法はmutexについては適用できる(というのは、他のコンストラクタを必要としないからだ)が、ここで作成したSmartPointerは実際うまく動かないだろう。なぜなら、smart pointerは、例えば、生ポインタを取るような他のコンストラクタが必要だからだ。そして、コンストラクタを提供してしまうと、コンパイラはデフォルトコンストラクタを作ることを求めてくる。これに従ってしまうと、このポインタを(実行時の)デフォルトコンストラクタが呼ばれる前に利用するのは未定義動作になってしまう。しかし、いかなるコンストラクタも持たないsmart pointer(mutexも同様)であっても、別の致命的な問題がある。それは、zero-initializationはglobalに対してのみ働く、ということだ。つまり、自動オブジェクトや動的に構築したオブジェクトについては初期値にゴミが入っていることになる(intやfloatやpointerやそれらの配列についてもそうであるのと同じく)。

C++11はzero-initializationのアイディアを拡張して、いかなるglobalの初期化についても十分シンプルに、コンパイル時に行われることが保証されるようにした。もう見当がついたかもしれないが、’十分シンプル’とはconstexpr関数ならびにconstexprコンストラクタと同じルールが適用できる、ということだ。constexpr関数をコンパイル時に評価し、複合型の構築に使うというのは、おそらく読者には目新しい情報ではないはずだ。しかし、ここでは、constではないオブジェクトの初期化について述べている。mutexは必要に応じて状態を変えなければならないから。

C++11のルールではどのようになっているのだろう？ 全てのglobalがzero-initializeされ、そのあとconstant initializationが行なわれる。 すなわち、コンパイル時定数、または初期値があるconstant expressionの評価によってのみ、globalオブジェクトは、globalの実行時初期化が行われる前、コンパイル時に初期化される。 それゆえ、初期化されたオブジェクトはそれ自体がコンパイル時定数でなくともよい(もちろんその場合、他のglobalのconstant initializationには使えないが)。

どう使うのだろう？ ほとんどなにもしなくてよい：

1   template <class T>
2   class SmartPointer
3   {
4     T * rawPtr_;
5     constexpr SmartPointer() noexcept : rawPtr_{nullptr} {};
6     // other constructors
7   };

この宣言は最初の例よりもなにやらぎこちなく見えるが、細かく見ていこう。constexprはこのconstructorがconstexpr-constructorであることを示している。すなわち、このクラスがリテラル型(しかし、このスマートポインタはそうではない)か、内包する式がすべて定数式で、静的初期化段階に実行することができるならばコンパイル時定数として作成できる。この特徴はユーザー型がリテラル型であることを要求しない。 noexceptはconstant initializationにおいて重要ではないが、(定数式としてコンパイル時に初期化できる程度に)簡単な関数を定義したとき、これは、失敗しない関数であり、例外の基本的な保証と強い保証を見たす構成要素として利用可能であることを示すという意味がある。 上記のスマートポインタクラスのコンストラクタはtrivialではない。trivial コンストラクタはrawPtr_をnull pointerに初期化しないので、ここでは明示的に初期化している。生ポインタをnull pointerに設定する処理は定数式である。よって、このコンストラクタは十分に単純であり、静的初期化が保証される。

さて、これが何をもたらすか？ SmartPointer<T> 型のglobalオブジェクトがデフォルトコンストラクタで初期化されるならば、コンパイル時に初期化処理が行われることが言語レヴェルで保証されているので、初期化順の問題にもう悩まされることはない。同時に、デフォルトコンストラクタ以外のコンストラクタは実行時に初期化される。globalはC++03と同じように生成する。

1   // at global namespace
2   SmartPointer<int> intPtr;

もう他にconstexprをタイプする必要はない(し、実際すべきでない)。デフォルトコンストラクタがconstexpr constructorとして定義されれば十分だ。intPtrはコンパイル時定数ではない。そしてまた ‘実行時定数’ でもないので、実行時に自由に値を変えることができる。これは単に初期化処理がコンパイル時に行なわれることが保証されているだけなのである。同様に、mutexについてもconstant initializationを保証できる:

1   class mutex
2   {
3     bool locked_;
4     SmartPointer<treadIdLink> threadsLocked_;
5     // invariant: if (!locked_) threadsLocked_ == nullptr;
6    
7     constexpr mutex() noexcept : locked_{false}, threadsLocked_{nullptr} {};
8   };

メンバ変数を0で初期化しなくてもよいので、以下のような実装も可能だ:

1   class mutex
2   {
3     bool youCanLockMe_;
4     SmartPointer<treadIdLink> threadsLocked_;
5     // invariant: if (youCanLockMe_) threadsLocked_ == nullptr;
6    
7     constexpr mutex() noexcept : youCanLockMe_{true}, threadsLocked_{nullptr} {};
8   };

しかしながら、ロックしたスレッドIDの保持にstd::vectorを使う実装に戻すことはできない。というのは、vectorのデフォルトコンストラクタはconstexpr constructorではない(し、そう仕様に要求されているわけでもない)からだ。

さて、我々はglobalクラスのコンパイル時初期化を可能にする道具を手にしたわけだが、constant initializationに依存している場合に注意すべき重要な問題がある。

globalの初期化が本当にコンパイル時に行なわれているかどうかを確認するのは困難である。もちろんバイナリを精査する手は残っているが、マルチプラットフォーム対応や、(デバッグやリテールのような)コンパイルモードを変える場合を考えてみれば、検査したバイナリに対しての保証でしかなく、プログラムに対する保証ではない。コンパイラはこの件に関して何の助けにもならない。コンパイラに、あるglobalがconstant initializeされているかどうか検査させる術はない。もしリテラル型の定数を初期化しているならば、以下のようにすればコンパイラに確認させることができる:

1   constexpr double x{1.0};
2   double y{2.0};              // ups! y is not a compile-time constant
3   const Complex c1{x, y};     // constant initialized at run-time
4   constexpr Complex c2{x, y}; // error: y is not a compile-time constant.

二番目のconstexprでコンパイラにc2を初期化する式が全て定数式かどうか(この場合ば’y’が定数式でない)を検証させている。しかしこれでは、constant initializationのみならず、オブジェクトの不変性も要求してしまっている。 もしconstant initializationだけが必要なら、constexpr指定子を使うことができない。しかしそれでは、不用意に定数式ではない(さらに型変換のような式は見えない)サブ式をたったひとつでも使ってしまっていたら、初期化は断りなく実行時に行なわれることになるだろう。 それゆえ、このような潜在的な問題を回避する最良の方法は、constant initializationは、不用意に’非定数式’を引数に取りようがないデフォルトコンストラクタだけに限ることである。

もうひとつ、constexpr関数/コンストラクタ テンプレートにまつわる問題がある。ある関数実体がconstexpr関数であるための条件をひとつでも満たしていない場合、コンパイラは断りなくconstexpr指定子を落してふつうの関数にすることが認められている(し、実際要求されている)。このため、mutexのように、’非テンプレート’型を用いるか、テンプレートパラメータTが与えられた場合、Tを操作する関数(テンプレート実装者からはどんな実装になっているか分からない)を呼ばないようにしたほうがより安全である。– 先のSmartPtrのように。

そしてこれはC++標準ライブラリでも多かれ少かれ採用されているガイドラインでもある。コンパイル時定数はさておき、静的初期化はstd::unique_ptrや、std::shared_ptr、std::weak_ptr、std::mutex、std::once_flagのような、型をnullptrで初期化するdefault constructorにのみ適用されている。 STLのコンテナにもおなじような保証がなされている、と思うかもしれない。その考えはたしかに筋が通っているが、標準ライブラリのプロバイダーからしてみると、実行時の効率など別の目的にもかなう柔軟性をライブラリに持たせるためには、このガイドラインが非常に大きな足枷になってしまう。

このガイドラインの興味深い例外として、std::atomicクラステンプレートが挙げられる。このクラステンプレートのデフォルトコンストラクタはconstexprではない(自動オブジェクトについてC言語と同じ実行時パフォーマンスを保証するために値は未初期化のままにしている)が、データコンストラクタはconstexprである。

ここではコンパイル時の初期化について多少誇張している。C++標準が本当に保証しているのはzero-initialization(0で初期化する)とconstant initialization(定数で初期化する)(これら二つの初期化はまとめて静的初期化(static initialization)と呼ばれる)が、プログラム上他の(動的)初期化よりも前に行われるということである。 それゆえ、静的初期化について、プログラム開始時のあるタイミングで行なわれても規格上は問題ない。だが、初期化順の問題を回避する、という目的を果たすために、またコンパイラ作者はただISO C++ 標準に従うだけではなく、市場のニーズ(例えばパフォーマンスなど)についても応えるよう努力するであろうから、このような初期化は、コンパイラによって、実行時コストなしで行なわれるのが自然であろう。

ここであらためて、もういちどconstexpr 関数/コンストラクタが持つ二つの役割について見ておこう:

1. 複合型のコンパイル時定数の作成および評価
2. 可変複合型globalオブジェクトのコンパイル時初期化

1. “Generalized constant expressions” — a sequence of proposals for generalizing constant expressions (N1521, N1972, N1980, N2116, N2235) by Gabriel Dos Reis, Bjarne Stroustrup and Jens Maurer.
2. The C++ International Standard. It used to be accessible from the Committee’s website. If you need to refer to an online resource, the latest standard draft — N3376 — is pretty similar in content. The following are the relevant places therein: § 3.6.2 (Initialization of non-local variables), § 3.8 (Object lifetime), § 5.19 (Constant expressions), § 7.1.5 (The constexpr specifier), § 8.5 (Initializers), § 12.1 (Constructors), § 12.9 (Inheriting constructors).
3. N2994: “constexpr in the libray: take 2” by Alisdair Meredith. It contains loads of useful information about constant initialization.