テンプレートをコンパイルするためには、C++ コンパイラは従来の UNIX コンパイラよりも多くのことを行う必要があります。C++ コンパイラは、必要に応じてテンプレートインスタンスのオブジェクトコードを生成します。コンパイラは、テンプレートリポジトリを使って、別々のコンパイル間でテンプレートインスタンスを共有することができます。また、テンプレートコンパイルのいくつかのオプションを使用できます。コンパイラは、別々のソースファイルにあるテンプレート定義を見つけ、テンプレートインスタンスと main コード行の整合性を維持する必要があります。
フラグ -verbose=template が指定されている場合は、 テンプレートコンパイル作業中の重要なイベントがユーザーに通知されます。逆に、デフォルトの -verbose=no%template が指定されている場合は、コンパイラは通知しません。そのほかに、+w オプション を指定すると、テンプレートのインスタンス化が行われたときに問題になりそうな内容が通知される場合があります。
CCadmin(1) コマンドは、テンプレートリポジトリを管理します (-instances=extern オプションを使用する場合のみ)。たとえば、プログラムの変更によって、インスタンス化が不要になり、記憶領域が無駄になることがあります。CCadmin の -clean コマンド (以前のリリースの ptclean) を使用すれば、すべてのインスタンス化と関連データを整理できます。インスタンス化は、必要なときだけ再作成されます。
コンパイラは、テンプレートインスタンス生成のため、インラインテンプレート関数をインライン関数として扱います。コンパイラは、インラインテンプレート関数をほかのインライン関数と同じように管理します。この章の内容は、テンプレートインライン関数には適用されません。
コンパイラは通常、テンプレートクラスのメンバーをほかのメンバーからは独立してインスタンス化するので、プログラム内で使用されるメンバーだけがインスタンス化されます。デバッガによる使用を目的としたメソッドは、通常はインスタンス化されません。
デバッグ中のメンバーを、デバッガから確実に利用できるようにするということは、次の 2 つを行うことになります。
第 1 に、実際には使用されないテンプレートクラスインスタンスメンバーを使用する、非テンプレート関数を作成します。この関数は呼び出されないようにする必要があります。
第 2 に、-template=wholeclass コンパイラオプションを使用します。このオプションを指定すると、非テンプレートで非インラインのメンバーのうちのどれかがインスタンス化された場合に、ほかの非テンプレート、非インラインのメンバーもすべてインスタンス化されます。
ISO C++ 標準では、特定のテンプレート引用により、すべてのメンバーが正当であるとはかぎらないテンプレートクラスを作成してよいと規定しています。不正メンバーをインスタンス化しないかぎり、プログラムは依然として適正です。ISO C++ 標準ライブラリでは、この技法が使用されています。ただし、-template=wholeclass オプションはすべてのメンバーをインスタンス化するので、問題のあるテンプレート引数を使ってインスタンス化する場合には、この種のテンプレートクラスに使用できません。
インスタンス化とは、C++ コンパイラがテンプレートから使用可能な関数やオブジェクトを作成するプロセスをいいます。C++ コンパイラ ではコンパイル時にインスタンス化を行います。つまり、テンプレートへの参照がコンパイルされているときに、インスタンス化が行われます。
コンパイル時のインスタンス化の長所を次に示します。
デバッグが非常に簡単である。エラーメッセージがコンテキストの中に発生するので、コンパイラが参照位置を完全に追跡することができる。
テンプレートのインスタンス化が常に最新である。
リンク段階を含めて全コンパイル時間が短縮される。
ソースファイルが異なるディレクトリに存在する場合、またはテンプレートシンボルを指定してライブラリを使用した場合には、テンプレートが複数回にわたってインスタンス化されることがあります。
デフォルトでは、インスタンスは特別なアドレスセクションに移動し、リンカーは重複を認識、および破棄します。コンパイラには、インスタンスの配置とリンケージの方法として、外部、静的、大域、明示的、半明示的のどれを使うかを指定できます。
外部 インスタンスは、次の条件が成立する場合に最大のパフォーマンスを達成します。
プログラムに含まれているインスタンス全体は小さいが、各コンパイル単位がそれぞれ参照するインスタンスが大きい。
2、3 個以上のコンパイル単位で参照されるインスタンスがほとんどない。
デフォルトである大域インスタンスは、あらゆる開発に適していますが、さまざまなインスタンスをオブジェクトが参照する場合に最適です。
半明示的インスタンスは、前述より多少管理の程度が緩やかなアプリケーションコンパイル環境に適しています。ただし、このインスタンスは明示的インスタンスより大きなオブジェクトファイルを生成し、用途はかぎられています。
この節では、5 つのインスタンスの配置とリンケージの方法について説明します。インスタンスの生成に関する詳細は、「6.3 テンプレートのインスタンス化」にあります。
外部インスタンスの場合では、すべてのインスタンスがテンプレートリポジトリ内に置かれます。テンプレートインスタンスは 1 つしか存在できません。つまり、インスタンスが未定義であるとか、重複して定義されているということはありません。テンプレートは必要な場合にのみ再インスタンス化されます。非デバッグコードの場合、すべてのオブジェクトファイル (テンプレートキャッシュに入っているものを含む) の総サイズは、-instances=extern を指定したときの値が -instances=global を指定したときの値より小さくなることがあります。
テンプレートインスタンスは、リポジトリ内では大域リンケージを受け取ります。インスタンスは、現在のコンパイル単位からは、 外部リンケージで参照されます。
コンパイルとリンクを別々に実行し、コンパイル処理で -instance=extern を指定する場合は、リンク処理でも -instance=extern を指定する必要があります。
この方法にはキャッシュが壊れる恐れがあるという欠点があります。そのため、別のプログラムに替えたり、大幅な変更をプログラムに対して行なったりした場合にはキャッシュをクリアーする必要があります。キャッシュへのアクセスを一度に 1 回だけに限定しなければならないため、キャッシュは、dmake を使用する場合と同じように、並列コンパイルにおけるボトルネックとなります。また、1 つのディレクトリ内に構築できるプログラムは 1 個だけです。
メインオブジェクトファイル内にインスタンスを作成したあと必要に応じて破棄するよりも、有効なテンプレートインスタンスがすでにキャッシュに存在しているかどうかを確認するほうが、時間がかかる可能性があります。
外部リンケージは、-instances=extern オプションによって指定します。
インスタンスはテンプレートリポジトリ内に保存されているので、外部インスタンスを使用する C++ オブジェクトをプログラムにリンクするには CC コマンドを使用しなければなりません。
使用するすべてのテンプレートインスタンスを含むライブラリを作成したい場合には、-xar オプション でCC コマンドを使用してください。ar コマンドは使用できません。たとえば、次のようにします。
example% CC– xar -instances=extern– o libmain.a a.o b.o c.o |
詳細は、表 15–3を参照してください。
-instance=extern を指定する場合、キャッシュの衝突の可能性があるため、異なるバージョンのコンパイラを同一ディレクトリ内で実行しないでください。-instances=extern テンプレートモデルを使用する場合は、次の点に注意してください。
同一ディレクトリ内に、無関係のバイナリを作成しないでください。すべてのバイナリ (.o、a、.so、実行可能プログラム) は関連している必要があります。これは、複数のオブジェクトファイルに共通のすべてのオブジェクト、関数、型の名前は、定義が同一であるためです。
dmake を使用する場合などは、複数のコンパイルを同一ディレクトリで同時に実行しても問題はありません。ほかのリンク段階と同時にコンパイルまたはリンク段階を実行すると、問題が発生する場合があります。リンク段階とは、ライブラリまたは実行可能プログラムを作成する処理を意味します。メイクファイル内での依存により、1 つのリンク段階での並列実行が禁止されていることを確認してください。
-instances=static オプションは、非推奨です。-instances=global が static の利点をすべて備えており、かつ欠点を備えていないので、-instances=static を使用する理由はなくなっています。このオプションは、今はもう存在していない問題を克服するために、以前のバージョンで提供されました。
静的インスタンスの場合は、すべてのインスタンスが現在のコンパイル単位内に置かれます。その結果、テンプレートは各再コンパイル作業中に再インスタンス化されます。インスタンスはテンプレートリポジトリに保存されません。
この方法の欠点は、言語の意味解釈が規定どおりでないこと、かなり大きいオブジェクトと実行可能ファイルが作られることです。
インスタンスは静的リンケージを受け取ります 。これらのインスタンスは、現在のコンパイル単位以外では認識することも使用することもできません。そのため、テンプレートの同じインスタンス化がいくつかのオブジェクトファイルに存在することがあります。複数のインスタンスによって不必要に大きなプログラムが生成されるので、静的インスタンスのリンケージは、テンプレートがインスタンス化される回数が少ない小さなプログラムだけに適しています。
静的インスタンスは潜在的にコンパイル速度が速いため、修正継続機能を使用したデバッグにも適しています。『dbx コマンドによるデバッグ』を参照してください。
プログラムがコンパイル単位間で、テンプレートクラスまたはテンプレート機能の静的データメンバーなどのテンプレートインスタンスの共有に依存している場合は、静的インスタンス方式は使用しないでください。プログラムが正しく動作しなくなります。
静的インスタンスリンケージは、-instances=static コンパイルオプションで指定します。
旧リリースのコンパイラとは異なり、新リリースでは、大域インスタンスの複数のコピーを防ぐ必要はありません。
この方法の利点は、ほかのコンパイラで通常受け入れられる正しくないソースコードを、このモードで受け入れられるようになったという点です。特に、テンプレートインスタンスの中からの静的変数への参照は正当なものではありませんが、通常は受け入れられるものです。
この方法の欠点は、テンプレートインスタンスが複数のファイルにコピーされることから、個々のオブジェクトファイルが通常より大きくなる可能性がある点です。デバッグを目的としてオブジェクトファイルの一部を -g オプションを使ってコンパイルし、ほかのオブジェクトファイルを -g オプションなしでコンパイルした場合、プログラムにリンクされるテンプレートインスタンスが、デバッグバージョンと非デバッグバージョンのどちらであるかを予測することは難しくなります。
テンプレートインスタンスは大域リンケージを受け取ります。これらのインスタンスは、現在のコンパイル単位の外でも認識でき、使用できます。
大域インスタンスは、-instances= global オプションで指定します。これがデフォルトです。
明示的インスタンスの場合、インスタンスは、明示的にインスタンス化されたテンプレートに対してのみ生成されます。暗黙的なインスタンス化は行われません。インスタンスは現在のコンパイル単位に置かれます。
この方法の利点はテンプレートのコンパイル量もオブジェクトのサイズも、ほかのどの方法より小さくて済むことです。
欠点は、すべてのインスタンス化を手動で行う必要がある点です。
テンプレートインスタンスは大域リンケージを受け取ります。これらのインスタンスは、現在のコンパイル単位の外でも認識でき、使用できます。リンカーは、重複しているものを見つけ、破棄します。
明示的リンケージは、 -instances=explicit オプションによって指定します。
半明示的インスタンスの場合、インスタンスは、明示的にインスタンス化されるテンプレートやテンプレート本体の中で暗黙的にインスタンス化されるテンプレートに対してのみ生成されます。明示的に作成されるインスタンスが必要とするインスタンスは自動的に生成されます。main コード行内で行う暗黙的なインスタンス化は不完全になります。インスタンスは現在のコンパイル単位に置かれます。したがって、テンプレートは再コンパイルごとに再インスタンス化されます。インスタンスが大域リンケージを受けることはなく、テンプレートリポジトリには保存されません。
半明示的インスタンスは、-instances=semiexplicit オプションで指定します。
必要なときだけテンプレートインスタンスがコンパイルされるよう、コンパイルからコンパイルまでのテンプレートインスタンスが テンプレートリポジトリに保存されます。テンプレートリポジトリには、外部インスタンスメソッドを使用するときにテンプレートのインスタンス化に必要となる非ソースファイルがすべて入っています。このリポジトリがほかの種類のインスタンスに使用されることはありません。
テンプレートリポジトリは、デフォルトで、キャッシュディレクトリ (SunWS_cache) にあります。
キャッシュディレクトリは、オブジェクトファイルが置かれるのと同じディレクトリ内にあります。SUNWS_CACHE_NAME 環境変数を設定すれば、キャッシュディレクトリ名を変更できます。SUNWS_CACHE_NAME 変数の値は必ずディレクトリ名にし、パス名にしてはならない点に注意してください。これは、コンパイラが、テンプレートキャッシュディレクトリをオブジェクトファイルディレクトリの下に自動的に入れることから、コンパイラがすでにパスを持っているためです。
コンパイラは、テンプレートインスタンスを格納しなければならないとき、出力ファイルに対応するテンプレートリポジトリにそれらを保存します。たとえば、次のコマンド行では、オブジェクトファイルを ./sub/a.o に、テンプレートインスタンスを ./sub/SunWS_cache 内のリポジトリにそれぞれ書き込みます。コンパイラがテンプレートをインスタンス化するときにこのキャッシュディレクトリが存在しない場合は、このディレクトリが作成されます。
example% CC -o sub/a.o a.cc |
コンパイラは、読み込むオブジェクトファイルに対応するテンプレートリポジトリからテンプレートインスタンスを読み取ります。つまり、次のコマンド行は、/sub1/SunWS_cache と /sub2/SunWS_cache を読み取り、必要な場合は ./SunWS_cache に書き込みます。
example% CC sub1/a.o sub2/b.o |
リポジトリ内にあるテンプレートは、ISO/ANSI C++ 標準の単一定義規則に違反してはいけません。つまり、テンプレートは、どの用途に使用される場合でも、1 つのソースから派生したものでなければなりません。この規則に違反した場合の動作は定義されていません。
この規則に違反しないようにするための、もっとも保守的で、もっとも簡単な方法は、1 つのディレクトリ内では 1 つのプログラムまたはライブラリしか作成しないことです。無関係な 2 つのプログラムが同じ型名または外部名を使用して別のものを意味する場合があります。これらのプログラムがテンプレートリポジトリを共有すると、テンプレートの定義が競合し、予期せぬ結果が生じる可能性があります。
-instances=extern を指定すると、テンプレートリポジトリマネージャーは、リポジトリ中のインスタンスの状態をソースファイルと確実に一致させて最新の状態にします。
たとえば、ソースファイルが -g オプション (デバッグ付き) でコンパイルされる場合には、データベースの中の必要なファイルも -g でコンパイルされます。
さらに、テンプレートリポジトリはコンパイル時の変更を追跡します。たとえば、-DDEBUG フラグ を指定して名前 DEBUG を定義すると、データベースがこれを追跡します。その次のコンパイルでこのフラグを省くと、コンパイラはこの依存性が設定されているテンプレートを再度インスタンス化します。
テンプレートのソースコードを削除する場合や、テンプレートの使用を停止する場合も、テンプレートのインスタンスはキャッシュ内にとどまります。関数テンプレートの署名を変更する場合も、古い署名を使用しているインスタンスはキャッシュ内にとどまります。これらの課題が原因でコンパイル時またはリンク時に予期しない動作が発生した場合は、テンプレートキャッシュをクリアし、プログラムを再構築してください。
定義分離型テンプレートの編成、つまりテンプレートを使用するファイルの中にテンプレートの宣言だけがあって定義はないという編成を使用している場合には、現在のコンパイル単位にテンプレート定義が存在しないので、コンパイラが定義を検索しなければなりません。この節では、そうした検索について説明します。
定義の検索はかなり複雑で、エラーを発生しやすい傾向があります。このため、可能であれば、定義取り込み型のテンプレートファイルの編成を使用したほうがよいでしょう。こうすれば、定義検索をまったく行わなくて済みます。「5.2.1 テンプレート定義の取り込み」を参照してください。
-template=no%extdef オプションを使用する場合、コンパイラは分離されたソースファイルを検索しません。
オプションファイルで提供されるような特定の指令がない場合には、コンパイラは Cfront 形式の方法でテンプレート定義ファイルを検出します。この方法の場合、テンプレート宣言ファイルと同じベース名がテンプレート定義ファイルに含まれている必要があります。また、テンプレート定義ファイルが現在の include パス上に存在している必要もあります。たとえば、テンプレート関数 foo() が foo.h 内にある場合には、それと一致するテンプレート定義ファイルの名前を foo.cc か、またはほかの認識可能なソースファイル拡張子 (.C、.c、.cc、.cpp、.cxx、または .c++) にしなければなりません。テンプレート定義ファイルは、通常使用する include ディレクトリの 1 つか、またはそれと一致するヘッダーファイルと同じディレクトリの中に置かなければなりません。
-I で設定する通常の検索パスの代わりに、-ptidirectory オプションでテンプレート定義ファイルの検索ディレクトリを指定することができます。複数の -pti フラグは、複数の検索ディレクトリ、つまり 1 つの検索パスを定義します。-ptidirectory を使用している場合には、コンパイラはこのパス上のテンプレート定義ファイルを探し、-I フラグを無視します。しかし、-ptidirectory フラグはソースファイルの検索規則を複雑にするので、-ptidirectory オプションの代わりに -I オプションを使用してください。
コンパイラがコンパイル対象ではないファイルを検索するために、紛らわしい警告あるいはエラーメッセージが生成されることがあります。通常、問題は、たとえば foo.h というファイルにテンプレート宣言が含まれていて、foo.cc などの別のファイルが暗黙で取り込まれることにあります。
ヘッダーファイル foo.h の中にテンプレート宣言が存在する場合は、コンパイラはデフォルトで、foo という名前および C++ のファイル拡張子 (.C、.c、.cc、.cpp、.cxx、または .c++) を持つファイルをデフォルトで検索します。そうしたファイルを見つけた場合、コンパイラはそのファイルを自動的に取り込みます。こうした検索の詳細は、「7.5 テンプレート定義の検索」を参照してください。
このように扱われるべきでないファイル foo.cc が存在する場合、選択肢は 2 つあります。
.h または .cc の名前を変更して、名前が一致しないようにする。
-template=no%extdef オプションを指定することによって、テンプレート定義ファイルの自動検索を無効にする。この場合は、すべてのテンプレート定義をコードに明示的に取り込む必要があります。このため、「定義分離」モデルは使用できなくなります。