ライブラリを使用すると、アプリケーション間でコードを共有したり、非常に大規模なアプリケーションを単純化できます。C++ コンパイラでは、さまざまなライブラリを使用できます。この章では、これらのライブラリの使用方法を説明します。
Solaris オペレーティングシステムでは、いくつかのライブラリが /usr/lib にイン ストールされます。このライブラリのほとんどは C インタフェースを持っています。デフォルトでは libc および libm ライブラリが CC ドライバによってリンクされます。ライブラリ libthread は、-mt オプションを指定した場合にのみリンクされます。それ以外のシステムライブラリをリンクするには、-l オプションでリンク時に指定する必要があります。たとえば、libdemangle ライブラリをリンクするには、リンク時に -ldemangle を CC コマンド行に指定します。
example% CC text.c -ldemangle |
C++ コンパイラには、独自の実行時ライブラリが複数あります。すべての C++ アプリケーションは、CC ドライバによってこれらのライブラリとリンクされます。C++ コンパイラには、次の節に示すようにこれ以外にも便利なライブラリがいくつかあります。
Sun C++ コンパイラには、いくつかのライブラリが添付されています。 これらのライブラリには、互換モード (-compat=4) だけで使用できるもの、標準モード (-compat=5) だけで使用できるもの、あるいは両方のモードで使用できるものがあります。libgc ライブラリと libdemangle ライブラリには C インタフェースがあり、どちらのモードでもアプリケーションにリンクできます。
次の表に、Sun C++ コンパイラに添付されるライブラリと、それらを使用できるモードを示します。
表 12–1 C++ コンパイラに添付されるライブラリ
ライブラリ |
内容の説明 |
使用できるモード |
---|---|---|
libstlport |
標準ライブラリの STLport 実装 |
-compat=5 |
libstlport_dbg |
デバッグモード用 STLport ライブラリ |
-compat=5 |
C++ 実行時 |
-compat=5 |
|
C++ 標準ライブラリ |
-compat=5 |
|
従来の iostream |
-compat=5 |
|
C++ 実行時、従来の iostream |
-compat=4 |
|
-xia オプションをサポート |
-compat=5 |
|
複素数ライブラリ |
-compat=4 |
|
librwtool |
Tools.h++ 7 |
-compat=4、-compat=5 |
デバッグ可能な Tools.h++ 7 |
-compat=4,-compat=5 |
|
ガベージコレクション |
C インタフェース |
|
復号化 |
C インタフェース |
STLport、Rogue Wave、または Sun Microsystems C++ ライブラリの構成マクロを再定義したり変更したりしないでください。ライブラリは C++ コンパイラとともに動作するよう構成および構築されています。libCstd と Tool.h++ は互いに働き合うように構成されているので、その構成マクロを変更すると、プログラムのコンパイルやリンクが行われなくなったり、プログラムが正しく実行されなくなったりします。
これらのライブラリについて簡単に説明します。
libCrun: このライブラリには、コンパイラが標準モード (-compat=5) で必要とする実行時サポートが含まれています。new と delete、例外、RTTI がサポートされます。
libCstd: これは C++ 標準ライブラリです。特に、このライブラリには iostream が含まれています。既存のソースで従来の iostream を使用している場合には、ソースを新しいインタフェースに合わせて修正しないと、標準 iostream を使用できません。詳細は、オンラインマニュアルの『Standard C++ Library Class Reference』を参照してください。
コンパイラソフトウェアが /opt ディレクトリにインストールされていない場合は、システム上でこのディレクトリに相当するパスをシステム管理者に問い合わせてください。
libiostream: これは標準モード (-compat=5) で構築した従来の iostream ライブラリです。既存のソースで従来の iostream を使用している場合には、libiostream を使用すれば、ソースを修正しなくてもこれらのソースを標準モード (-compat=5) でコンパイルできます。このライブラリを使用するには、-library=iostream を使用します。
標準ライブラリのほとんどの部分は、標準 iostream を使用することに依存しています。従来の iostream を同一のプログラム内で使用すると、問題が発生する可能性があります。
libC: これは互換モード (-compat=4) で必要なライブラリです。このライブラリには C++ 実行時サポートだけでなく従来の iostream も含まれています。
libcomplex: このライブラリは、互換モード (-compat=4) で複素数の演算を行うときに必要です。標準モードの場合は、libCstd の複素数演算の機能が使用されます。
libstlport: これは、C++ 標準ライブラリの STLport 実装です。このライブラリを使用するには、デフォルトの libCstd の代わりにオプション -library=stlport4 を指定します。ただし、libstlport と libCstd の両方を同一プログラム内で使用することはできません。インポートしたライブラリを含み、すべてをどちらか一方のライブラリだけを使ってコンパイルしリンクする必要があります。
librwtool (Tools.h++): Tools.h++ は、RogueWave の C++ 基礎クラスライブラリです。Version 7 が提供されています。このライブラリは廃止され、新しいコードでこのライブラリを使用することは非推奨です。RW Tools.h++ を使用していた、C++ 4.2 用に作成されたプログラムに対応する目的で、このライブラリは提供されています。
libgc: このライブラリは、展開モードまたはガベージコレクションモードで使用します。libgc ライブラリにリンクするだけで、プログラムのメモリーリークを自動的および永久的に修正できます。プログラムを libgc ライブラリとリンクする場合は、free や delete を呼び出さずに、それ以外は通常どおりにプログラムを記述できます。ガベージコレクションライブラリは、動的読み込みライブラリと依存関係があるため、プログラムのリンクでは、-lgc および -ldl を指定します。
詳細については、gcFixPrematureFrees(3) および gcInitialize(3) のマニュアルページを参照してください。
libdemangle: このライブラリは、C++ 符号化名を復号化するときに使用します。
この節で説明しているライブラリに関するマニュアルページは1、3、3C++、および 3cc4 の各節にあります。
C++ ライブラリのマニュアルページにアクセスするには次のとおり入力してください。
example% man library-name |
C++ ライブラリの Version 4.2 のマニュアルページにアクセスするには次のコマンドを入力してください。
example% man -s 3CC4 library-name |
これらのライブラリには、CC ドライバによってデフォルトでリンクされるものと、明示的にリンクしなければならないものがあります。標準モードでは、次のライブラリが CC ドライバによってデフォルトでリンクされます。
互換モード (-compat) では、次のライブラリがデフォルトでリンクされます。
-lC -lm -lc
詳細は、「A.2.50 -library=l[ ,l...]」 を参照してください。
CC ドライバには、ライブラリを使用するためのオプションがいくつかあります。
マルチスレッド化コードをコンパイルしてリンクするには、-mt オプションを使用します。
区間演算ライブラリをリンクするには、-xia オプションを使用します。
Fortran または C99 実行時ライブラリをリンクするには、-xlang オプションを使用します。
Sun C++ コンパイラに添付された次のライブラリを指定するには、-library オプションを使用します。
libCrun
libCstd
libiostream
libC
libcomplex
libstlport、libstlport_dbg
librwtool、librwtool_dbg
libgc
librwtool の従来の iostream 形式を使用するには、-library=rwtools7 オプションを使用します。librwtool の標準 iostream 形式を使用するには、-library=rwtools7_std オプションを使用します。
-library オプションと -staticlib オプションの両方に指定されたライブラリは静的にリンクされます。次にその例を挙げます。
次のコマンドでは Tools.h++ Version 7 の従来の iostream 形式と libiostream ライブラリが動的にリンクされます。
example% CC test.cc -library=rwtools7,iostream |
次のコマンドでは libgc ライブラリが静的にリンクされます。
example% CC test.cc -library=gc -staticlib=gc |
次のコマンドでは test.cc が互換モードでコンパイルされ、libC が静的にリンクされます。互換モードでは libC がデフォルトでリンクされるので、このライブラリを -library オプションで指定する必要はありません。
example% CC test.cc -compat=4 -staticlib=libC |
次のコマンドでは ライブラリ libCrunおよび libCstd がリンク対象から除外されます。指定しない場合は、これらのライブラリは自動的にリンクされます。
example% CC test.cc -library=no%Crun,no%Cstd |
デフォルトでは、CC は、指定されたコマンド行オプションに従ってさまざなシステムライブラリをリンクします。-xnolib (または -nolib) を指定した場合、CC は、-l オプションを使用してコマンド行で明示的に指定したライブラリだけをリンクします。-xnolib または -nolib を使用した場合、-library オプションが存在していても無視されます。
-R オプションは、動的ライブラリの検索パスを実行可能ファイルに組み込むときに使用します。実行時リンカーは、実行時にこれらのパスを使ってアプリケーションに必要な共有ライブラリを探します。CC ドライバは、デフォルトで -R<install_directory/lib を ld に渡します (コンパイラが標準の場所にインストールされている場合)。共有ライブラリのデフォルトパスが実行可能ファイルに組み込まれないようにするには、-norunpath を使用します。
配備用に構築するプログラムは、コンパイラのディレクトリでライブラリを参照することを防止する -norunpath または -R オプションを使用して構築するべきです (「12.6 共有ライブラリの使用」を参照してください)。
一般に、クラスライブラリを使用するには 2 つの手順が必要です。
ソースコードに適切なヘッダーをインクルードする。
プログラムをオブジェクトライブラリとリンクする。
C++ コンパイラには、2 通りの iostream が実装されています。
従来の iostream。この用語は、C++ 4.0、4.0.1、4.1、4.2 コンパイラに添付された iostream ライブラリ、およびそれ以前に cfront ベースの 3.0.1 コンパイラに添付された iostream ライブラリを指します。このライブラリの標準はありませんが、既存のコードの多くがこれを使用しています。このライブラリは、互換モードの libC の一部であり、標準モードの libiostream にもあります。
標準の iostream。これは C++ 標準ライブラリ libCstd に含まれていて、標準モードだけで使用されます。これは、バイナリレベルでもソースレベルでも「従来の iostream」とは互換性がありません。
すでに C++ のソースがある場合、そのコードは従来の iostream を使用しており、次の例のような形式になっていると思われます。
// file prog1.cc #include <iostream.h> int main() { cout << "Hello, world!" << endl; return 0; } |
次のコマンドは、互換性モードで prog1.cc をコンパイル、リンクして、prog1 という実行可能なプログラムを生成します。従来の iostream ライブラリは、互換性モードのときにデフォルトでリンクされる libC ライブラリに含まれています。
example% CC -compat prog1.cc -o prog1 |
次の例では、標準 iostream が使用されています。
// file prog2.cc #include <iostream> int main() { std::cout << "Hello, world!" << std::endl; return 0; } |
次のコマンドは、prog2.cc をコンパイル、リンクして、prog2 という実行可能なプログラムを生成します。コンパイルは標準モードで行われ、このモードでは、標準の iostream ライブラリを含む libCstd がデフォルトでリンクされます。
example% CC prog2.cc -o prog2 |
libCstd についての詳細は、「警告:」を参照してください。libiostream の詳細は、「13.3.1 再配布とサポートされる STLport ライブラリ」を参照してください。
コンパイルモードの詳しい説明については、『C++ 移行ガイド』を参照してください。
標準ライブラリには、C++ 4.2 コンパイラに付属していた complex ライブラリに似た、テンプレート化された complex ライブラリがあります。標準モードでコンパイルする場合は、<complex.h> ではなく、<complex> を使用する必要があります。互換性モードで <complex> を使用することはできません。
互換性モードでは、リンク時に complex ライブラリを明示的に指定しなければなりません。標準モードでは、complex ライブラリは libCstd に含まれており、デフォルトでリンクされます。
標準モード用の complex.h ヘッダーはありません。C++ 4.2 では、「complex」 はクラス名ですが、標準 C++ では「complex」はテンプレート名です。したがって、旧式のコードを変更せずに動作できるようにする typedef を使用することはできません。このため、複素数を使用する、4.2 用のコードで標準ライブラリを使用するには、多少の編集が必要になります。たとえば、次のコードは 4.2 用に作成されたものであり、互換性モードでコンパイルされます。
// file ex1.cc (compatibility mode) #include <iostream.h> #include <complex.h> int main() { complex x(3,3), y(4,4); complex z = x * y; cout << "x=" << x << ", y=" << y << ", z=" << z << endl; } |
次の例では、ex1.cc を互換モードでコンパイル、リンクし、生成されたプログラムを実行しています。
example% CC -compat ex1.cc -library=complex example% a.out x=(3, 3), y=(4, 4), z=(0, 24) |
次は、標準モードでコンパイルされるように ex2.cc と書き直された ex1.cc です。
// file ex2.cc (ex1.cc rewritten for standard mode) #include <iostream> #include <complex> using std::complex; int main() { complex<double> x(3,3), y(4,4); complex<double> z = x * y; std::cout << "x=" << x << ", y=" << y << ", z=" << z << std::endl; } |
次の例では、書き直された ex2.cc をコンパイル、リンクして、生成されたプログラムを実行しています。
% CC ex2.cc % a.out x=(3,3), y=(4,4), z=(0,24) |
複素数演算ライブラリの使用方法についての詳細は、表 14–4 を参照してください。
次の表は、C++ ライブラリにリンクするためのコンパイラオプションをまとめています。詳細は、「A.2.50 -library=l[ ,l...]」を参照してください。
表 12–2 C++ ライブラリにリンクするためのコンパイラオプション
ライブラリ |
コンパイルモード |
オプション |
---|---|---|
-compat=5 |
不要 -library=iostream |
|
complex |
-compat=4 -compat=5 |
-library=complex 不要 |
-compat=4 -compat=5 |
-library=rwtools7 -library=rwtools7_std |
|
デバッグ対応 Tools.h++ Version 7 |
-compat=4 -compat=5 |
-library=rwtools7_dbg -library=rwtools7_dbg,iostream -library=rwtools7_std_dbg |
-compat=4 -compat=5 |
-library=gc -library=gc |
|
STLport Version 4 |
-compat=5 |
-library=stlport4 |
STLport Version 4 デバッグ |
-compat=5 |
-library=stlport4_dbg |
デフォルト時、CC ドライバは、デフォルトライブラリの -llib オプションをリンカーに渡すことによって、libc と libm を含むいくつかのライブラリの共有バージョンでリンクします。互換性モードと標準モードにおけるデフォルトライブラリのリストについては、「12.2.3 デフォルトの C++ ライブラリ」を参照してください。
このようにデフォルトのライブラリを静的にリンクする場合、-library オプションと -staticlib オプションを一緒に使用すれば、C++ ライブラリを静的にリンクできます。この方法は、以前説明した方法よりもかなり簡単です。たとえば、次のようにします。
example% CC test.c -staticlib=Crun |
この例では、-library オプションが明示的にコマンドに指定されていません。標準モード (デフォルトのモード) では、-library のデフォルトの設定が Cstd,Crun であるため、-library オプションを明示的に指定する必要はありません。
あるいは、-xnolib コンパイラオプションも使用できます。-xnolib オプションを指定すると、ドライバは自動的には -l オプションを ld に渡しません。次の例は、Solaris 8 または Solaris 9 オペレーティングシステムで libCrun と静的に、libm および libc と動的にリンクする方法を示します。
example% CC test.c– xnolib– lCstd– Bstatic– lCrun– Bdynamic– lm– lc |
-l オプションの順序は重要です。-lCstd、-lCrun、および -lm オプションは、-lc の前に表示します。
libCrun および libCstd を静的にリンクすることはお勧めできません。/usr/lib 内の動的バージョンは、インストール先の Solaris のバージョンで動作するよう構築します。
ほかのライブラリにリンクする CC オプションもあります。そうしたライブラリへのリンクも -xnolib によって行われないように設定できます。たとえば、-mt オプションを指定すると、CC ドライバは、-lthread を ld に渡します。これに対し、-mt と-xnolib の両方を使用すると、CC ドライバは ld に -lthread を渡しません。詳細は、「A.2.153 -xnolib」を参照してください。ld については、Solaris に関するマニュアル『リンカーとライブラリ』を参照してください。
/lib および /usr/lib にある Solaris ライブラリの静的バージョンは、もう使用できません。たとえば、libc を静的にリンクしようとする試みは、失敗します。
CC hello.cc -xnolib -lCrun -lCstd -Bstatic -lc |
次の C++ 実行時共有ライブラリは、C++ コンパイラの一部として出荷されています。
libCCexcept.so.1 (SPARC Solaris のみ)
libcomplex.so.5 (Solaris のみ)
librwtool.so.2
libstlport.so.1
Linux では、次の追加ライブラリが C++ コンパイラの一部として出荷されています。
libCrun.so.1
libCstd.so.1
libdemangle.so
libiostream.so.1
Solaris では、次の追加ライブラリがほかのライブラリとともに、C++ 実行時ライブラリパッケージである SUNWlibC の一部としてインストールされます。
アプリケーションが、C++ コンパイラの一部として出荷されている共有ライブラリのいずれかを使用している場合は、CC ドライバは runpath に調整を加え (-R オプションを参照)、実行可能ファイルの構築に使用するライブラリの場所を指すようにします。あとで、同じバージョンのコンパイラを同じ場所にインストールしていないコンピュータに実行可能ファイルを配備する場合は、必要な共有ライブラリが見つかりません。
プログラムの起動時に、ライブラリはまったく見つからない、あるいは誤ったバージョンのライブラリが使用される可能性があり、プログラムの正しくない動作につながります。このような状況では、必要なライブラリをプログラムと共に出荷し、それらのライブラリのインストール場所を指す runpath を指定して構築を行うべきです。
『Using and Redistributing Sun Studio Libraries in an Application』という資料には、このトピックに関する詳細な説明と例が掲載されていて、http://developers.sun.com/sunstudio/documentation/techart/stdlibdistr.html から入手できます。
ただし、コンパイラに添付された標準ライブラリを置き換えることは危険で、必ずしもよい結果につながるわけではありません。基本的な操作としては、コンパイラに添付されている標準のヘッダーとライブラリを無効にして、新しいヘッダーファイルとライブラリが格納されているディレクトリとライブラリ自身の名前を指定します。
コンパイラは、標準ライブラリの STLport 実装をサポートします。詳細は、「13.3 STLport」を参照してください。
ほとんどの標準ライブラリおよびそれに関連するヘッダーは置き換え可能です。置き換えるライブラリが libCstd である場合は、次の関連するヘッダーも置き換える必要があります。
<algorithm> <bitset> <complex> <deque> <fstream <functional> <iomanip> <ios> <iosfwd> <iostream> <istream> <iterator> <limits> <list> <locale> <map> <memory> <numeric> <ostream> <queue> <set> <sstream> <stack> <stdexcept> <streambuf> <string> <strstream> <utility> <valarray> <vector>
ライブラリの置き換え可能な部分は、いわゆる「STL」と呼ばれているもの、文字列クラス、iostream クラス、およびそれらの補助クラスです。このようなクラスとヘッダーは相互に依存しているため、それらの一部を置き換えるだけでは通常は機能しません。一部を変更する場合でも、すべてのヘッダーと libCstd のすべてを置き換える必要があります。
標準ヘッダー <exception>、<new>、および <typeinfo> は、コンパイラ自身とlibCrun に密接に関連しているため、これらを置き換えることは安全ではありません。ライブラリ libCrun は、コンパイラが依存している多くの「補助」関数が含まれているため置き換えることはできません。
C から派生した 17 個の標準ヘッダー (<stdlib.h>、<stdio.h>、<string.h> など) は、Solaris オペレーティングシステムと基本 Solaris 実行時ライブラリ libc に密接に関連しているため、これらを置き換えることは安全ではありません。これらのヘッダーの C++ 版 (<cstdlib>、<cstdio>、<cstring> など) は基本の C バージョンのヘッダーに密接に関連しているため、これらを置き換えることは安全ではありません。
代替ライブラリをインストールするには、まず、代替ヘッダーの位置と libCstd の代わりに使用するライブラリを決定する必要があります。理解しやすくするために、ここでは、ヘッダーを /opt/mycstd/include にインストールし、ライブラリを /opt/mycstd/lib にインストールすると仮定します。ライブラリの名前は libmyCstd.a であると仮定します。なお、ライブラリの名前を lib で始めると後々便利です。
コンパイルごとに -I オプションを指定して、ヘッダーがインストールされている位置を指示します。さらに、-library=no%Cstd オプションを指定して、コンパイラ独自のバージョンの libCstd ヘッダーが検出されないようにします。たとえば、次のようにします。
example% CC -I/opt/mycstd/include -library=no%Cstd... (compile) |
-library=no%Cstd オプションを指定しているため、コンパイル中、コンパイラ独自のバージョンのヘッダーがインストールされているディレクトリは検索されません。
プログラムまたはライブラリのリンクごとに -library=no%Cstd オプションを指定して、コンパイラ独自の libCstd が検出されないようにします。さらに、-L オプションを指定して、代替ライブラリがインストールされているディレクトリを指示します。さらに、-l オプションを指定して、代替ライブラリを指定します。次に例を示します。
example% CC -library=no%Cstd -L/opt/mycstd/lib -lmyCstd... (link) |
あるいは、-L や -l オプションを使用せずに、ライブラリの絶対パス名を直接指定することもできます。たとえば、次のようにします。
example% CC -library=no%Cstd /opt/mycstd/lib/libmyCstd.a... (link) |
-library=no%Cstd オプションを指定しているため、リンク中、コンパイラ独自のバージョンの libCstd はリンクされません。
C には、<stdio.h>、<string.h>、<stdlib.h> などの 17 個の標準ヘッダーがあります。これらのヘッダーは Solaris オペレーティングシステムに標準で付属しており、/user/include に置かれています。C++ にも同様のヘッダーがありますが、さまざまな宣言の名前が大域の名前空間と std 名前空間の両方に存在するという条件が付加されています。Version 8 より前のリリースの Solaris オペレーティングシステムの C++ コンパイラでは、/usr/include ディレクトリにあるヘッダーはそのまま残して、独自のバージョンのヘッダーを別に用意しています。
また、C++ には、C 標準ヘッダー (<cstdio> 、<cstring>、<cstdlib> など) のそれぞれについても専用のバージョンがあります。C++ 版の C 標準ヘッダーでは、宣言名は std 名前空間にのみ存在します。C++ には、32 個の独自の標準ヘッダー (<string>、<utility>、<iostream> など) も追加されています。
標準ヘッダーの実装で、C++ ソースコード内の名前がインクルードするテキストファイル名として使用されているとしましょう。たとえば、標準ヘッダーの <string> (または <string.h>) が、あるディレクトリにある string (または string.h) というファイルを参照するものとします。この実装には、次の欠点があります。
ヘッダーファイルにファイル名接尾辞 (拡張子) がない場合に、ヘッダーファイルのみを検索すること、またはヘッダーファイルに関する規則を示す makefile を作成することができない。
string というディレクトリまたは実行可能プログラムがあると、そのディレクトリまたはプログラムが標準ヘッダーファイルの代わりに検出される可能性がある。
Solaris 8 オペレーティングシステムより前のリリースの Solaris オペレーティングシステムでは .KEEP_STATE が有効なときのメイクファイルのデフォルトの相互依存関係により、標準ヘッダーが実行可能プログラムに置き換えられる可能性がある (デフォルトの場合、接尾辞がないファイルは構築対象プログラムとみなされる)。
こうした問題を解決するため、コンパイラの include ディレクトリには、ヘッダーと同じ名前を持つファイルと、 一意の接尾辞 .SUNWCCh を持つ、そのファイルへのシンボリックリンクが含まれています。 SUNW はコンパイラに関係するあらゆるパッケージに対する接頭辞、CC は C++ コンパイラの意味、.h はヘッダーファイルの通常の接尾辞です。つまり <string> と指定された場合、コンパイラは <string.SUNWCCh> と書き換え、その名前を検索します。接尾辞付きの名前は、コンパイラ専用の include ディレクトリにだけ存在します。このようにして見つけられたファイルがシンボリックリンクの場合 (通常はそうである)、コンパイラは、エラーメッセージやデバッガの参照でそのリンクを 1 回だけ間接参照し、その参照結果 (この場合は string) をファイル名として使用します。ファイルの依存関係情報を送るときは、接尾辞付きの名前の方が使用されます。
この名前の書き換えは、2 つのバージョンがある 17 個の標準 C ヘッダーと 32 個の標準 C++ ヘッダーのいずれかを、パスを指定せずに山括弧 < > で囲んで指定した場合にだけ行われます。山括弧の代わりに引用符が使用されるか、パスが指定されるか、ほかのヘッダーが指定された場合、名前の書き換えは行われません。
次の表は、よくある書き換え例をまとめています。
表 12–3 ヘッダー検索の例
ソースコード |
コンパイラによる検索 |
注釈 |
---|---|---|
<string> |
string.SUNWCCh |
C++ の文字列テンプレート |
<cstring> |
cstring.SUNWCCh |
C の string.h の C++ 版 |
<string.h> |
string.h.SUNWCCh |
C の string.h |
<fcntl.h> |
fcntl.h |
標準 C および C++ ヘッダー以外 |
"string" |
string |
山括弧ではなく、二重引用符 |
<../string> |
../string |
パス指定がある場合 |
コンパイラが header.SUNWCCh (header はヘッダー名) を見つけられない、コンパイラは、#include 指令で指定された名前で検索し直します。たとえば、#include <string> という指令を指定した場合、コンパイラは string.SUNWCCh という名前のファイルを見つけようとします。この検索が失敗した場合、コンパイラは string という名前のファイルを探します。
「12.7.5 標準ヘッダーの実装」で説明している検索アルゴリズムのため、「12.7.3 代替ライブラリのインストール」で説明している SUNWCCh バージョンの代替 ヘッダーを指定する必要はありません。しかし、これまでに説明したいくつかの問題が発生する可能性もあります。その場合、推奨される解決方法は、接尾辞が付いていないヘッダーごとに、接尾辞 .SUNWCCh を持つファイルに対してシンボリックリンクを作成することです。つまり、ファイルが utility の場合、次のコマンドを実行します。
example% ln -s utility utility.SUNWCCh |
utility.SUNWCCh というファイルを探すとき、コンパイラは 1 回目の検索でこのファイルを見つけます。そのため、utility という名前のほかのファイルやディレクトリを誤って検出してしまうことはありません。
標準 C ヘッダーの置き換えはサポートされていません。それでもなお、独自のバージョンの標準ヘッダーを使用したい場合、推奨される手順は次のとおりです。
すべての代替ヘッダーを 1 つのディレクトリに置きます。
そのディレクトリ内にある代替ヘッダーごとに header.SUNWCCh (header はヘッダー名) へのシンボリックリンクを作成します。
コンパイラを呼び出すごとに -I 指令を指定して、代替ヘッダーが置かれているディレクトリが検索されるようにします。
たとえば、<stdio.h> と <cstdio> の代替ヘッダーがあるとします。stdio.h と cstdio をディレクトリ /myproject/myhdr に置きます。このディレクトリ内で、次のコマンドを実行します。
example% ln -s stdio.h stdio.h.SUNWCCh example% ln -s cstdio cstdio.SUNWCCh |
コンパイルのたびに、オプション -I/myproject/mydir を使用します。
C ヘッダーを置き換える場合は、対になっているもう一方のヘッダーを置き換える必要があります。たとえば、<time.h> を置き換えるときは、<ctime> も置き換える必要があります。
代替ヘッダーは、置き換える前のヘッダーと同じ効果を持っている必要があります。これは、さまざまな実行時ライブラリ (libCrun、libC、libCstd、libc、および librwtool) が標準ヘッダーの定義を使用して構築されているためです。同じ効果を持っていない場合、作成したプログラムはほとんどの場合、正しく動作しません。