更新日付: 2003 年 3 月 28 日

Sun[tm] ONE Studio 8: C++ コンパイラ Readme

目次

  1. はじめに
  2. Sun ONE Studio 8、C++ コンパイラについて
  3. 新規および変更された機能
  4. ソフトウェアの修正事項
  5. 問題点と回避策
  6. 制限事項と互換性の問題
  7. 記述の誤りの訂正
  8. ライブラリの再配布について
  9. 未対応の言語仕様

 

A. はじめに

この文書では、Sun Open Net Environment (Sun ONE) Studio 8, Compiler Collection の C++ コンパイラに関する情報を提供します。この文書では当コンパイラを C++ コンパイラのバージョン 5.5 と呼ぶ場合があります。 また、この文書では今回のリリースで提供される新機能やソフトウェアの修正事項について解説するとともに、既知の問題や制限事項、および互換性の問題について説明しています。この文書の記載内容はソフトウェアマニュアルの情報を更新または補充します。

製品マニュアル

注 - Compiler Collection ソフトウェアがデフォルトの /opt ディレクトリにインストールされていない場合は、システム上の対応するパスをシステム管理者に確認してください。 このマニュアルの索引からアクセスできる C++ マニュアルは以下のとおりです。

この文書のテキスト版を表示するには、コマンドプロンプトで次のコマンドを入力します。

        CC -xhelp=readme

この文書の HTML 版を表示するには、次のファイルにアクセスします。 

   file:/opt/SUNWspro/docs/ja/index.html

 

B. Sun ONE Studio 8、C++ コンパイラについて

このリリースの C++ コンパイラは、Solaris[tm] オペレーティング環境 SPARC (R); プラットフォーム版の バージョン 7、8、9 と、Solaris オペレーティング環境 x86 プラットフォーム版のバージョン7、8、9 で利用できます。

このバージョン 5.5 の C++ コンパイラは、バージョン 5.0、5.1、5.2、5.3、5.4、および 5.5 の C++ コンパイラのソースコードおよびバイナリコードと上方互換です。すなわち、C++ 5.5 コンパイラを使用して、バージョン 5.0、5.1、5.2、5.3、および 5.4 の C++ コンパイラ用に作成されたソースコードをコンパイルできます。また、バージョン 5.0、5.1、5.2、5.3、5.4 の C++ コンパイラによって生成されたオブジェクトコードを C++ 5.5 コンパイラで生成されたオブジェクトコードとリンクできます。リンクする場合は、常に最新のコンパイラ、つまり今回のリリースであるバージョン 5.5 を使用してください。

C++ 5.5 コンパイラには、C++ 4.2 コンパイラ用に作成されたソースコードをコンパイルするための -compat オプションも用意されています。-compat オプションは、バージョン 5.0 から導入されたオプションです。

 

C. 新規および変更された機能

ここでは、このリリースで C++ コンパイラに新たに追加された機能と変更された機能を説明します。Sun ONE Studio 8 のその他のコンポーネントについては、『Sun ONE Studio 8 の新機能』を参照してください。ローカルシステムまたはネットワーク上でこのマニュアルにアクセスするには、file:/opt/SUNWspro/docs/ja/index.html を開いてください。http://docs.sun.com にも同じマニュアルが掲載されています。

一般的な機能向上
テンプレートキャッシュは不要:-instances
変数スコープにリンカーマップファイルは不要: -xldscope
マクロ用に強力な診断機能を追加:-xdumpmacros
VIS[tm] Developers Kit のサポート:-xvis (SPARC)
C99 実行時ライブラリと実行時環境のサポート: -xlang=c99
UTF-16 文字列リテラルのサポート:-xustr
OpenMP のサポート拡大:-xopenmp
改良された -xprofile (SPARC)

より高速なコンパイル
構文チェックの高速化:-xe
-xprofile_ircache による高速なプロファイリング (SPARC)
重複したテンプレートインスタンス化の停止: -instlib=filename
-template=geninlinefuncs による関数生成
プリコンパイル済みヘッダー、-xpch
-xjobs=n による複数プロセッサの使用 (SPARC)

容易な移植
-xmemalign による移植の簡易化
-xchar による char の符号の設定
-xport64 による移植されたコードのデバッグ

パフォーマンスの向上
リンカーによってサポートされる、データのスレッドローカルな記憶領域を使用した実行時性能の向上:-xthreadvar (SPARC)
ページフォルトを減らすことにより実行時性能の向上: -xF
新しいプラグマによる実行時性能の向上
Link-Time Optimizer による実行時性能の向上: -xlinkopt (SPARC)
-xpagesize=n による実行時性能の向上 (SPARC)

警告制御とエラー制御の追加
-erroff による警告メッセージのフィルタリング
-errtags と -errwarn によるコンパイルの中止
-filt=[no%]stdlib による、標準ライブラリ名のフィルタリングの向上

 

テンプレートキャッシュは不要:-instances

この C++ コンパイラリリースでは、テンプレートのインスタンス化機能が大幅に向上しています。デフォルトのテンプレートインスタンス化モデルを使用するプログラムは、1 つのディレクトリ内で 1 つのプログラムしか構築できないという制限を受けることがなくなりました。

代替インスタンス化モデル (-instances=static など) に依存するほとんどのプログラムも、新しいデフォルトのインスタンス化モデルを使用できるようになりました。

テンプレートインスタンス化機能の向上と変更によりテンプレートキャッシュが不要になったため、コンパイル時間を短縮できます。また、静的関数の重複を避けることができるため、実行プログラムのサイズ縮小にもつながります。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -instances を参照してください。

変数スコープにリンカーマップファイルは不要: -xldscope

今回のリリースでは、動的ライブラリ内のシンボルのエクスポートを制御するのに 2 種類の方法を利用できるようになりました。この機能はリンカースコープと呼ばれ、最近になってリンカーマップファイルによってサポートされるようになったものです。まず、このリリースからはコード内に新しい宣言指定子を埋め込むことができるようになりました。__global、__symbolic、および __hidden をコード内に直接埋め込めばよく、マップファイルを使用する必要がありません。もう 1 つの方法は、コマンド行で -xldscope を指定することによって変数スコープのデフォルト設定を上書きするものです。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xldscope を参照してください。宣言指定子の詳細は、『C++ ユーザーズガイド』の第 4 章「Language Extensions」で述べられています。

マクロ用に強力な診断機能を追加:-xdumpmacros

このリリースでは、アプリケーション内のマクロ動作の追跡に便利なように、新しいプラグマが 2 つと新しいコンパイラオプションが 1 つ追加されました。これには、システムヘッダー内に定義されるマクロも含まれます。

コマンド行で -xdumpmacros オプションを使用することで、マクロ定義を確認したり、プログラムのどこでマクロの定義、定義の解除、マクロの使用がなされているかを確認したりできます。焦点を絞るには、ソース内で直接新しい dumpmacros プラグマと end_dumpmacros プラグマを使用してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xdumpmacros を参照してください。

VIS Developers Kit のサポート:-xvis (SPARC)

VIS 命令セット Software Developers Kit (VSDK) で定義されているアセンブリ言語テンプレートを使用している場合は、-xvis=[yes|no] オプションを使用してください。デフォルトは -xvis=no です。

VIS 命令セットは、SPARC v9 命令セットの拡張機能です。 UltraSPARC プロセッサは 64 ビットですが、さまざまなケースがあり、特にマルチメディアアプリケーションではデータサイズが 8 ビットまたは 16 ビットに限定されることがあります。VIS 命令は 1 つの命令で 4 つの 16 ビットデータを処理できるため、イメージング、線形代数、シグナル処理、オーディオ、ビデオ、ネットワーキングなどのようなニューメディアを処理するアプリケーションのパフォーマンスを大幅に向上させます。

VSDK についての情報は、http://www.sun.com/processors/vis を参照してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xvis を参照してください。

C99 実行時ライブラリと実行時環境のサポート: -xlang=c99

C99 規格 (ISO/IEC 9899:1999、プログラミング言語 - C) をサポートするオペレーティングシステムでは、-xlang=c99 は C ライブラリ関数を呼び出す C コードおよび C++ コードの C99 実行時動作を指定します。C99 動作の中には、C 複素数型のように C コンパイラでの -xc99=%all オプションの使用に依存するものもあれば、printf のようにこのオプションに左右されないものもあります。

C99 サポートはコンパクトモード (-compat=4) では使用できないことに注意してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xlang を参照してください。

UTF-16 文字列リテラルのサポート:-xustr

ISO10646 UTF-16 文字列リテラルを使用する国際化されたアプリケーションをサポートする必要がある場合は、-xustr=ascii_utf16_ushort を指定してください。つまりこのオプションは、オブジェクトファイルを生成する場合に UTF-16 文字列に変換させたい文字列リテラルがコードに含まれる場合に使用します。このオプションを指定しないと、コンパイラは 16 ビットの単純文字列リテラルの生成、認識を行いません。このオプションを指定すると、U"ASCII_string" 文字列リテラルは符号なし短整数として認識されます。 このような文字列はどの規格でもまだ取り入れられていませんが、 このオプションを使用することで規格外の C++ を認識させることができます。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xustr を参照してください。

OpenMP のサポート拡大:-xopenmp

C++ コンパイラは明示的並列化のための OpenMP インタフェースの実装を継続しています。

C++ コンパイラは、次のように OpenMP 機能を拡張しました。

次の例は、OpenMP 並列領域におけるクラスオブジェクトの使用と、クラスメンバー関数内における OpenMP 構文の使用を示しています。

#include <omp.h>
class A{
public:
    int i;
    A(){i = 5;};          // コンストラクタ
    A(const A& a){ i = a.i;};    // コピーコンストラクタ
    A& operator=(const A& a)      // 代入処理
    {
        if (this != &a)
          i = a.i;
        return *this;
    };
    ~A(){};			  // デストラクタ
    void foo();
};

void A::foo()             // プラグマを使用したメンバー関数
{
  #pragma omp parallel
      	i = omp_get_thread_num();
}

main()
{
  A a, b, c;
  b.i = 10;
  c.i = 100;
  // OpenMP データ節で使用されるクラスオブジェクト
  #pragma omp parallel private(a) firstprivate(b)
  {
        #pragma omp for lastprivate(c) private(a) // 再固有化
        for(int i = 0; i < 50; i++)
            c.i = i * a.i;
        a = b;
  }
  a.foo();
}

次に、有効な OpenMP プログラムを処理する上での既知の問題点を示します。

このコンパイラオプションの詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xopenmp を参照してください。 Sun の OpenMP 実装の詳細は、Sun ONE Studio 8 Compiler Collection『OpenMP API ユーザーズガイド』を参照してください。

改良された -xprofile (SPARC)

-xprofile オプションは次のように改良されました。

-xprofile=use を使用することで、コンパイラは一意ではないベース名を持つ複数のオブジェクトファイルのデータが保存されたプロファイルディレクトリで、プロファイルデータを見つけることができるようになりました。コンパイラがオブジェクトファイルのプロファイルデータを検出できない場合は、コンパイラは新しいオプション -xprofile_pathmap=collect-prefix: use-prefix を提供します。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xprofile と -xprofile_pathmap を参照してください。

構文チェックの高速化:-xe

-xe を指定した場合、コンパイラは構文エラーと意味上の誤りをチェックするだけで、オブジェクトコードは生成しません。

-xe オプションは、コンパイルによってオブジェクトファイルを生成する必要がない場合に使用してください。たとえば、コードの一部を削除してエラーメッセージの原因をなくそうとしている場合は、-xe を使用することで編集とコンパイルの作業をスピードアップできます。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xe を参照してください。

-xprofile_ircache による高速なプロファイリング (SPARC)

収集フェーズで保存されたコンパイルデータを再使用することによって使用フェーズのコンパイル時間を短縮させたい場合は、
-xprofile_ircache[=path] と -xprofile=collect|use を併用してください。

大きなプログラムの場合は、中間データが保存されるため、使用フェーズのコンパイル時間が大幅に短縮されます。データを保存することでディスク容量の要件が相当拡大する可能性があることに注意してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xprofile_ircache を参照してください。

重複したテンプレートインスタンス化の停止: -instlib=filename

-instlib=filename は、ライブラリと現在のオブジェクトでテンプレートインスタンスが重複して生成されることを禁止する場合に使用してください。 一般に、プログラムが多数のインスタンスをライブラリと共有する場合は、-instlib=filename を試し、コンパイル時間が短縮するかどうかを確認してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -template、-instances、および -pti を参照してください。

-template=geninlinefuncs による関数生成

通常 C++ コンパイラは、関数が呼び出されてインライン化が不可能な場合を除き、インラインテンプレート関数を生成しません。しかし、-template=geninlinefuncs を指定すると、それまでは生成されることがなかった、インスタンス化されたクラステンプレートのインラインメンバー関数をインスタンス化します。これらの関数のリンケージは、すべてのケースともローカルです。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -template を参照してください。

プリコンパイル済みヘッダー、-xpch

このコンパイラリリースでは、プリコンパイル済みヘッダーという新機能を提供しています。プリコンパイル済みヘッダーファイルを使用すると、大容量ソースコードを持つ共通のインクルードファイルセットをソースファイルが共有している場合にアプリケーションのコンパイル時間を短縮できる場合があります。これは、1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルする場合や、同じヘッダー群を持つほかのソースファイルをコンパイルする場合にその情報を使用するという方法で行われます。この機能は、-xpch オプションと -xpchstop オプションを #pragma hdrstop 指令と併用することで利用できます。

詳細は、CC(1) の -xpch オプションと -xpchstop オプションを参照してください。Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』でも、これらのオプションと #pragma hdrstop の詳細が示されています。

-xjobs=n による複数プロセッサの使用 (SPARC)

-xjobs=n オプションは、作業を行うためにコンパイラが作成するプロセスの数を設定するために指定します。このオプションは、マルチ CPU マシンにおけるビルド時間を短縮する効果があります。現在、-xjobs は -xipo オプションとの併用でしか機能しません。-xjobs=n を指定すると、相互手続きオプティマイザはさまざまなファイルをコンパイルするために呼び出すことができるコードジェネレータインスタンスの最大数として n を使用します。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xjobs を参照してください。

-xmemalign による移植の簡易化

-xmemalign オプションは、データ整列に関するコンパイラの前提を制御するために使用します。境界整列を誤ったメモリーアクセスが起きないようにコードジェネレータを制御し、かつ境界整列を誤ったアクセスが起きた場合にプログラムの動作を制御することで、Solaris にコードを移植しやすくなります。

-xmemalign オプションは、必要以上に境界整列が行われたデータのパフォーマンスを高めたり、通常よりも密にパッケージ化された構造体にアクセスする場合にも使用されます。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -memalign を参照してください。

-xchar による char の符号の設定

-xchar[={signed|s|unsigned|u}] オプションは、char 型が「符号なし」と定義されたシステムからのコード移植を簡易化するためのものです。このようなシステムから移植を行う場合を除き、このオプションを使用しないでください。記述を変更して「符号付き」または「符号なし」と明示的に指定する必要があるのは、char 型の符号に依存するコードだけです。 詳細は、『C++ ユーザーズガイド』または CC(1) を参照してください。

-xport64 による移植されたコードのデバッグ

この新しい -xport64 オプションは、64 ビット環境にコードを移植する場合に使用してください。このオプションを使用すると、V7 (ILP32) などの 32 ビットアーキテクチャから V9 (LP64) などの 64 ビットアーキテクチャへコードを移植する場合によく発生する値 (ポインタを含む) の切り捨て、符号拡張、ビットパッキングへの変更などの問題が警告されます。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xport64 を参照してください。

リンカーによってサポートされる、データのスレッドローカルな記憶領域を使用した実行時性能の向上:-xthreadvar (SPARC)

新しいスレッドローカルな記憶領域機能にはリンカーによってサポートされます。次の作業に使用してください。

このリリースのコンパイラでは、スレッドローカル変数の宣言を通してスレッドローカルな記憶領域を使用できます。この宣言には、変数指定子 __thread の追加による通常の変数宣言と、コマンド行オプション -xthreadvar による宣言があります。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xthreadvar を参照してください。宣言指定子の詳細は、『C++ ユーザーズガイド』の第 4 章「言語拡張」で説明しています。

ページフォルトを減らすことにより実行時性能の向上: -xF

この新機能 -xF は、リンカーによる変数と関数の並べ替えを最適にするために使用します。この機能を使用すると、実行時のパフォーマンスに悪影響を与える次のような問題を解決しやすくなります。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xF を参照してください。

新しいプラグマによる実行時性能の向上

C++ コンパイラは、コードの最適化に有効なプラグマを新たに 4 つサポートするようになりました。これらのプラグマの詳細は、『C++ ユーザーズガイド』を参照してください。

詳細は、Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の付録 B「プラグマ」を参照してください。

Link-Time Optimizer による実行時性能の向上: -xlinkopt (SPARC)

-xlinkopt コマンドを指定することで、C++ コンパイラは再配置可能なオブジェクトファイルに対してリンク時の最適化を実施できるようになりました。CC(1) を参照してください。

-xlinkopt を指定すると、リンク時にコンパイラはリンクされている .o ファイルを変更することなく付加的な最適化を実施します。 この最適化が出現するのは、実行可能プログラム内だけです。-xlinkopt オプションは、プログラム全体をコンパイルする時に、プロファイルのフィードバックとともに使用するともっとも効果的です。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xlinkopt を参照してください。

-xpagesize=n による実行時性能の向上 (SPARC)

-xpagesize=n オプションは、スタックとヒープのページサイズを設定する場合に使用します。n には、8K、64K、512K、4M、32M、256M、2G、16G、または default を指定できます。対象プラットフォームの Solaris オペレーティング環境に有効なページサイズ (getpagesize(3C) で表示されるサイズ) を指定してください。有効なページサイズを指定しないと要求は実行時に無視され、それを知らせるメッセージは表示されません。対象プラットフォームのページサイズは、pmap(1) または meminfo(2) で確認できます。

このオプションは、-xpagesize_stack と -xpagesize_heap のマクロです。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -xpagesize、-xpagesize_heap、および -xpagesize_stack を参照してください。

-erroff による警告メッセージのフィルタリング

このリリースでは、新しい -erroff オプションを使用して警告メッセージがコンパイラのフロントエンドに現れないようにすることができるようになりました。ただし、エラーメッセージとドライバからのメッセージには適用されません。 特定の警告メッセージに -erroff を適用し、その警告メッセージだけが抑制されるようにすることも、あるいはその警告メッセージだけが発行されるようにすることも可能です。

たとえば、-erroff=tag は tag に指定された警告メッセージを抑制します。一方、-erroff=%all,no%tag は、tag で特定されるメッセージを除くすべての警告メッセージを抑制します。 警告メッセージのタグは、-errtags=yes オプションを使用して表示できます。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -erroff を参照してください。

-errtags と -errwarn によるコンパイルの中止

このリリースでは、コンパイラオプション -errtags と -errwarn を使用し、コンパイラが特定の警告を発行する場合にコンパイルを停止できるようになりました。 まず特定の警告のタグを見つけるために -errtags=yes を設定し、続いて -errwarn=tag を指定します (tag は特定メッセージに対して -errtags が返す一意の識別子)。

また、-errwarn=%all を使用し、どの警告が発行されてもコンパイルを中止するように指定することもできます。CC(1) の -xwe も参照してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -errtags と -errwarn を参照してください。

-filt=[no%]stdlib による標準ライブラリ名のフィルタリングの向上

デフォルトでは、リンカーとコンパイラのエラーメッセージ内の標準ライブラリの名前が簡易化されるように、-filt=[no%]stdlib オプションが設定されています。 このため、ユーザーは標準ライブラリ関数の名前を簡単に認識できます。このフィルタリングを無効にする場合は、-filt=no%stdlib を指定してください。

詳細は、CC(1) または Sun ONE Studio 8 Compiler Collection『C++ ユーザーズガイド』の -filt を参照してください。

 

D. ソフトウェアの修正事項

ここでは、次のソフトウェアの修正事項について説明します。

  1. あいまいな表現 : コンストラクタ呼び出しまたは関数へのポインタ
  2. Solaris 8 update 2 およびパッチにおける ctype 未定義エラーの修正
  3. -instance=static および -instance=semiexplicit とテンプレート内の静的変数のサポート
  4. 関数にローカルな静的変数に対する extern インライン関数の動作の違い
  5. テンプレートの構文エラーの検出
  6. -staticlib オプションと -G の同時指定が可能
  1. あいまいな表現 : コンストラクタ呼び出しまたは関数へのポインタ

    C++ では、あるときは宣言と解釈されたり、またあるときは式と解釈される可能性がある文があります。C++ のあいまい排除規則では、ある文を宣言文とみなすことができる場合は、その文は宣言文とすることになっています。

    以前のバージョンのコンパイラでは、次のような事例を誤って解釈していました。

        struct S {
      S();
    };
    struct T {
      T( const S& );
    };
    T v( S() );    // ???

    このプログラマはおそらく、最後の行で S 型の一時的な値で初期化される変数 v を定義するつもりでした。以前のバージョンのコンパイラは、この文をそのように解釈していました。

    しかし、宣言コンテキスト内のコンストラクト、"S()" は、"S 型の値を戻すパラメータのない関数" を意味する抽象宣言子 (識別子のない抽象宣言子) とみなすこともできます。この事例では、関数ポインタ、"S(*)()" に自動的に変換されています。この文はまた、戻り値が T 型で、パラメータが関数ポインタ型の関数 v の宣言としても有効です。

    現在ではコンパイラが正しい解釈をするようになったので、このプログラマが意図したようにならない可能性があります。

    あいまいにならないようにコードを修正するには、次の 2 通りの方法があります。

        T v1( (S()) );  // v1 は、初期化されるオブジェクト
    T v2( S(*)() ); // v2 は、関数

    1 行目の 1 対の余分な括弧は、v1 の構文が関数宣言としては不正であるので、"S 型の一時的な値で初期化される T 型のオブジェクト" という意味にしか解釈できません。

    同様に、コンストラクト、"S(*)()" は値とは考えられないので、関数宣言の意味にしか解釈できません。

    最初の行は、次のように書くこともできます。

        T v1 = S();

    意味は完全に明確になりますが、この初期設定の形式では、通常はそうでもないとはいえ、一時的な値として非常に大きな値が生成されることがあります。

    次のようにコーディングするのはお勧めできません。その理由は、意味が不明確で、コンパイラが異なると結果が異なる可能性があるからです。

        T v( S() ); // 推奨しない
  2. Solaris 8 update 2 およびパッチにおける __ctype 未定義エラーの修正

    Solaris 8 オペレーティング環境に問題があり、<stdlib.h> の MB_CUR_MAX を使用すると、 C++ コンパイラから「__ctype は定義されていません」というエラーが返されることがあります。

    このバグは、Solaris 8 update 2 オペレーティング環境で修正されました。これは、Solaris パッチ 109607-01 (SPARC)、109608-01 (IA) でも修正されています。

    このアップデート版またはパッチをインストールしていない場合、この問題を回避するには、ヘッダー <stdlib.h> をインクルードする前に標準ヘッダー <ctype.h> をインクルードしてください。

  3. -instance=static および -instance=semiexplicit とテンプレート内の静的変数のサポート

    以前のバージョンの C++ コンパイラでは、テンプレート内の静的変数に対する静的インスタンスメソッドと半明示的インスタンスメソッドがサポートされていませんでした。バージョン 5.2、5.3、5.4 および 5.5 の C++ コンパイラでは、この制限が解除されています。

  4. 関数にローカルな静的変数に対する extern インライン関数の動作の違い

    ARM 規則では、extern インライン関数の関数にローカルな静的変数はファイルに対して静的です。ISO 規格では、extern インライン関数の関数にローカルな静的変数は、コンパイルユニット間で共有されるグローバル変数です。

    バージョン 5.0 および 5.1 の C++ コンパイラでは、互換 (-compat) および標準 (デフォルトのモード) のどちらのモードでも ARM の動作が実装されていました。これに対し、バージョン 5.2、5.3、5.4 および 5.5 の C++ コンパイラでは、互換モードで ARM の動作、標準モードで ISO の動作が実装されています。以下にその例を示します。

    one.cc

    inline int inner() {
      static int variable = 0; return variable++;
    }
    int outer() { return inner(); }

two.cc

    inline int inner() {
      static int variable = 0; return variable++;
    }
    int main() { return inner() + outer(); }

    互換モード (-compat) でコンパイルした場合、この 2 つの変数は異なり、main の結果は 0 になります。

    標準モード (デフォルトモード) でコンパイルした場合は、この 2 つの変数が同じになり、main の結果は 1 になります。 標準モードで古い動作にするには、インライン関数を static に宣言します。

  5. テンプレートの構文エラーの検出

    次のテンプレートの構文は不正ですが、Sun C++ 4 および 5.0 では、エラーになりませんでした。バージョン 5.1、5.2、5.3、5.4 および 5.5 の C++ コンパイラでは、構文エラーとして報告されます (デフォルトの標準モードでコンパイルした場合)。

      template<class T> class MyClass<T> { ... }; // 定義エラー
  template<class T> class MyClass<T>;         // 宣言エラー

    どちらの場合も、「MyClass<T>」の「<T>」は不正で、次の例に示すように削除する必要があります。

      template<class T> class MyClass { ... }; // 定義
  template<class T> class MyClass;         // 宣言
  6. -staticlib オプションと -G の同時指定が可能

    以前は、-staticlib オプションには、共有ライブラリを構築する場合には無効でした。現在は有効です。

 

E. 問題点と回避策

ここでは、これまでにわかっているソフトウェアの問題点とその回避策について説明します。更新情報については、アップデート情報 http://sun.co.jp/software/sundev/suncc/hotnews.html を参照してください。

  1. コンパイル済み .i ファイルがコンパイラエラーを生成する
  2. 言語間リンクエラー
  3. リンク時の名前符号化の問題
  4. Solaris オペレーティング環境バージョン 7 における make と標準ライブラリヘッダーファイルの問題
  5. デバッグツールから、メンバー関数に余分な先行パラメータがあるという誤ったメッセージが返される
  6. 大域的ではない名前空間のオブジェクトをテンプレートから参照できない
  7. 名前空間内の #pragma align と符号化名
  8. 関数の多重定義の解決
  9. 代替スレッドを使用したマルチスレッド対応の C++ プログラムは、Solarais 8 オペレーティング環境でデバッグするとハングアップする
  1. コンパイル済み .i ファイルがコンパイラエラーを生成する

    __global は、新しい xldscope コンパイラオプションの一部として C++ 5.5 で追加されたキーワードです。前処理済みの .i ファイルを古いコンパイラを使用して生成し、続いてこの .i ファイルをバージョン 5.5 でコンパイルする場合、.i ファイル内でキーワード __global が識別子として使用されていると、エラーメッセージが表示されることがあります。

    この問題を解決するには、.i ファイルの先頭に #pragma disable_ldscope を追加してください。このコードが古いコンパイラを対象としている場合は、新しいリンカースコーピングキーワード (__global など) は使用できません。 ほかのファイルにインクルードする場合は、.i ファイルの最後に #pragma enable_ldscope という行を追加できます。

  2. 言語間リンクエラー

    -xlang=f77 コマンドを実行すると、コンパイルプロセス中にリンカーエラーが発生します。エラーを回避するとともに適切な実行時ライブラリをインクルードするには、代わりに -xlang=f77,f90 を実行します。

  3. リンク時の名前符号化の問題

    次の場合に、リンク時に問題が発生することがあります。

    • const パラメータ付きで宣言されている関数が、別の場所で const パラメータなしで宣言されている。

      例:

        void foo1(const int);
  void foo1(int);

      これらの宣言は等価ですが、コンパイラは異なる符号化名を付けます。この問題を回避するには、値のパラメータを const として宣言しないでください。たとえば、関数定義の本体などのあらゆる場所で void foo1(int);

    • 関数に同じ複合型のパラメータが 2 つあり、一方のパラメータだけ typedef で宣言されている。

      例:

        class T;
  typedef T x;
  // foo2 は複合型(ポインタまたは配列)
  // パラメータ型
  void foo2(T*, T*)
  void foo2(T*, x*);
  void foo2(x*, T*);
  void foo2(x*, x*);

      すべての foo2 宣言は等価で、これらは同様:w に符号化される必要があります。しかし、コンパイラは一部に異なった符号化を行なっています。この問題を回避するには、一貫して typedef を使用します。

      typedef を一貫して使用できない場合は、回避策として、関数を定義しているファイルに weak シンボルを使用し、宣言とその定義を等価にします。次に例を示します。

      #pragma weak "__1_undefined_name" = "__1_defined_name"

      注 -- 一部の符号化名は、ターゲットアーキテクチャによって異なります。たとえば、size_t は SPARC V9 アーキテクチャでは unsigned long ですが、それ以外のアーキテクチャでは unsigned int です。これは、2 つの異なったバージョンの符号化名がそれぞれ 1 つのモデルに存在するケースです。このような場合は、2 つのプラグマを用意し、適切な #if 指令で制御する必要があります。

    詳細は、『C++ 移行ガイド』を参照してください。このマニュアルの HTML 版にアクセスするには、ブラウザで file:/opt/SUNWspro/docs/ja/index.html を開きます。

  4. Solaris オペレーティング環境バージョン 7 における make と標準ライブラリヘッダーファイルの問題

    標準ライブラリファイル名には「.h」接尾辞が付いていません。その代わりに、istream、fstream などの名前が付けられています。また、テンプレートのソースファイルには istream.cc、fstream.cc などの名前が付けられています。

    Solaris 7 オペレーティング環境で <istream> のような標準ライブラリヘッダーをプログラムにインクルードする場合、makefile に .KEEP_STATE があると、問題が発生します。たとえば、 <istream> がインクルードされると、make は istream を実行可能とみなし、デフォルトの規則に基づいて istream.cc から istream を構築しようとします。その結果、誤解を招くエラーメッセージが返されます。istream と istream.cc はともに、C++ インクルードファイルディレクトリにインストールされています。以下に、取りうる回避策を示します。

    • -r オプションを使用して、デフォルトの make 規則を無効にする。この方法を使用すると、構築プロセスが停止することがあります。
    • make の代わりに、dmake ユーティリティを逐次モードで使用する。dmake -m serial
    • .KEEP_STATE の使用を避ける。

  5. デバッグツールから、メンバー関数に余分な先行パラメータがあるという誤ったメッセージが返される

    互換モード (-compat=4) では、C++ コンパイラはメンバー関数を指すポインタのリンク名を正しく符号化しません。このエラーのため、復号化プログラムおよび、dbx や c++filt などのデバッグツールから、メンバー関数に余分な先行パラメータ (メンバー関数が属しているクラスタイプを示す) があると報告されます。この問題を解決するには、-Qoption ccfe -abiopt=pmfun1 フラグを追加します。しかし、一般に、このフラグを使用してソースをコンパイルすると、このフラグなしでコンパイルしたソースとの間のバイナリレベルの互換性が失われることがあります。標準モード (デフォルトモード) では、名前の符号化に関する問題はありません。 

  6. 大域的ではない名前空間のオブジェクトをテンプレートから参照できない

    プログラムでテンプレートと静的オブジェクトを使用していると、未定義シンボルのリンク時エラーが発生します。現在コンパイラは、大域的でない名前空間スコープのオブジェクトに対するテンプレートからの参照をサポートしません。次の例で考えてみます。

    static int k;
template<class T> class C {
        T foo(T t) { ... k ... }
};

    この例では、テンプレートクラスのメンバーは名前空間スコープ変数を参照します。名前空間スコープはファイルスコープを含むことに注意してください。コンパイラは、名前空間スコープ変数を参照するテンプレートクラスのメンバーをサポートしません。複数のコンパイル単位からテンプレートがインスタンス化されると、各インスタンスは異なる k を参照します。つまり、C++ ODR (One-Definition Rule) 違反が発生し、コードは定義されていない動作を起こします。

    ユーザーは、k をどのように使用したいか、k によってどのような効果を得たいかにもとづき、次に示す代替方法を実施できます。クラスメンバーではない関数テンプレートの場合、選択できるのは最初のオプションと 3 つ目のオプションだけです。

    1. 変数に外部リンケージを持たせる 
      int k; // 静的ではない
      すべてのインスタンスは、k の同じコピーを使用します。
    2. 変数をクラスの静的メンバーにする 
      template<class T> class C {
        static int k;
        T foo(T t) { ... k ... }
};;
      静的なクラスメンバーは外部リンケージを持ちます。各 C<T>::foo インスタンスは、個別の k を使用します。C<T>::k のインスタンスは、ほかの関数で共有できます。通常はこのオプションが使用されます。

    3. 変数を関数に対してローカルにする

      template<class T> class C {
             T foo(T t) { static int k; ... k ... }
};

      各 C<T>::foo インスタンスは、関数の外部からは見えない独自の k のコピーを使用します。

  7. 名前空間内の #pragma align と符号化名

    名前空間内で #pragma align を使用する場合は、符号化名を使用する必要があります。たとえば、次のコードでは、#pragma align 文は何の働きもしません。この問題を解決するには、#pragma align 文内の a、b、および c をそれぞれの符号化名に置き換える必要があります。

      namespace foo {
    #pragma align 8 (a, b, c) // 有効でない
    // 符号化名を使用:
    #pragma aling 8 (__1cDfooBa_, __1cDfooBb_, __1cDfooBc_)
    static char a;
    static char b;
    static char c;
  }
  8. 関数の多重定義の解決

    C++ コンパイラの以前のリリースでは、C++ 標準の要件に従って、関数の多重定義の解決を行いませんでした。今回のリリースでは、多重定義された関数の呼び出しを解決して、多くのバグを修正しています。特に、コンパイラは、呼び出しが実際にあいまいな場合は関数をピッキングしたり、実際にはそうでない場合にも、呼び出しがあいまいであると表示したりする場合がありました。

    あいまいであることを示すメッセージに関する回避策には、不要なものもあります。 以前には報告されなかった、あいまいに関する新しいエラーが発生しています。

    あいまいな関数呼び出しの主な原因の 1 つは、組み込み型のサブセットにさえも多重定義が発生することです。

       
int f1(short);
int f1(float);
...
f1(1); // あいまい。1" は int 型
f1(1.0); // あいまい。1.0" は double 型

    この問題を修正するには、f1 を決して多重定義しないか、あるいは拡張されないすべての型 (int、unsigned int、long、unsigned long、および double) で多重定義を行います (long long、unsigned long long、および long double 型がある場合もあります)。

    もう 1 つの主な原因はクラスにおける型変換関数で、特に多重定義された演算子が存在する場合です。

    class T {
public:
        operator int();
        T(int);
        T operator+(const T&);
};
T t;
1 + t // あいまい

    この演算は、次のように解決できるので、あいまいです

    T(1) + t     // 多重定義された演算子
1 + t.operator int()    // 組み込みの int を追加

    多重定義された演算子または型変換関数を使用できますが、両方使用すると、あいまいと判断されます。

    実際、型変換関数そのものは、あいまいと判断されたり、意図しなかった場所で変換が発生したりすることがたびたびあります。変換を有効にする必要がある場合は、型変換関数ではなく名前付き関数を使用してください。たとえば、operator int();

    この変更により、演算子 1 + t はあいまいではなくなります。 T(1) + t としか解釈できません。ほかの解釈を望む場合は、1 + t.to_int() と記述する必要があります。

  9. 代替スレッドを使用したマルチスレッド対応の C++ プログラムは、Solarais 8 オペレーティング環境でデバッグするとハングアップする

    代替スレッドを使用して構築した、マルチスレッド対応の C++ プログラムは、Solari 8 オペレーティング環境でデバッグしようとすると、ハングアップします。-R /usr/lib/lwp コンパイラオプションで構築した 32 ビットマルチスレッド対応の C++ プログラムは、dbx で実行するとハングアップします。-R /usr/lib/lwp/sparcv9 コンパイラオプションで構築した 64 ビットマルチスレッド対応の C++ プログラムは、実行時検査を行なっている場合には特に、ハングアップする可能性があります。

    この現象は、C++ コードを標準 (デフォルト) モードで (-compat=5 コンパイラオプションを使用して) コンパイルした場合に起こります。互換モードで (-compat コンパイラオプションを使用して) コンパイルした場合には起こりません。

    パフォーマンス調整として代替スレッドの使用を考えている場合、デフォルトのスレッドライブラリを使用して、マルチスレッド対応のプログラムを最初にデバッグすることを強くお勧めします。代替スレッドは、その後で使用してください。

 

F. 制限事項と互換性の問題

ここでは、制限事項およびシステムまたはその他のソフトウェアとの互換性の問題について説明します。

  1. 次に、C++ コンパイラの 5.5 リリースで明らかになっている OpenMP の制限事項を示します。
    • 並列領域で宣言される静的なクラスオブジェクト

      現時点では、OpenMP 領域内における静的なクラスオブジェクトの宣言を Sun はサポートしていません。このような宣言が見つかると、エラーが生成されます。このエラーを生成するコードの例を示します。 

      #pragma omp parallel
{
  static A a;		// A はクラスの型
  :
}
Error: Static non-POD decl not allowed in parallel region.

      次のようにコードを変更すると、望ましい動作が得られます。 

      {
  A a;
  #pragma omp parallel // shared がデフォルト
  {
    :
  }
}
    • 標準のテンプレートライブラリ

      OpenMP の並列領域で std::string を使用すると、コンパイルエラーまたは実行時エラーが発生する可能性があります。stlport4 ライブラリを使用することでこの問題が回避できる場合もあります。

    • OpenMP データ節で使用されるクラスメンバー変数

      Sun は、OpenMP データ節に対するクラスメンバー変数の記述はサポートしていません。次に、同じ動作を実現するための処理を示します。

      • shared

        shared (デフォルト) と宣言せずに OpenMP 並列領域でメンバー変数を使用します。

      • private

        並列領域で適切な型の新しい変数が使用されるように宣言します。

      • firstprivate

        並列領域内で適切な型の新しい変数を宣言し、(shared) メンバー変数の値でこの変数を初期化します。

      • lastprivate

        並列領域の外で適切な型の新しい変数を宣言し、これを lastprivate 節に配置し、exit のあとでその値をメンバー変数に代入します。

    • catch ブロック内の並列領域

      catch ブロック内に OpenMP 領域が出現すると、コンパイラエラーが生成されます。 

        
try() {
    :
}

catch(...) {
  #pragma omp parallel
  {

  }
}
    • OpenMP についてはコマンド行切り替え -xF=%all はサポートされない

      この切り替えを使用すると、実行時セグメント例外を引き起こす可能性があります。

    • 並列領域での firstprivate と omp for における後続の使用

      クラスオブジェクトが動的メモリーを割り当てるコピーコンストラクタを持ち、このオブジェクトが並列領域に firstprivate として渡され、その後 omp for 領域で使用された場合は、不正な結果が生成されたり、セグメント例外が発生したりします。次に、問題が発生する可能性があるコードの例を示します。 

      int main(void)
{
    int i;
    vector<int> v(10);

    for (i = 0; i < 10; i++)
	v[i] = 0;

    #pragma omp parallel firstprivate(v)
    {
	#pragma omp for
	for (i = 0; i < 10; i++)
	    v[i] = omp_get_thread_num();
    }
}

      上記の例では、a.i[j] のコンテンツが破損するか、セグメント例外が発生します。次に、この問題を解決するコード例を示します。

      #pragma omp parallel shared(v)
{
	vector<int> tmp = v;
	#pragma omp for
	for (i = 0; i < 10; i++)
	    tmp[i] = omp_get_thread_num();
}
  2. x86 における最適化でリンカースコープが機能しない

    バグ報告 4829700 で説明しているように、x86 で -xldscope=hidden または -xldscope=symbolic を指定すると、最適化 -O または -xO[1|2|3|4|5] で -xldscope オプション が機能しません。

  3. -xia と -library=stlport4 の互換性の問題

    C++ の区間演算を STLport C++ ライブラリとともに使用することはできません。-xia オプションを使用するプログラムは、『C++ Interval Arithmetic Programming Reference』の説明どおりにコンパイルおよびリンクすることしかできません。

  4. C++ 共有ライブラリのパッチ

    各対応プラットフォームについて、今回のリリースの Sun ONE Studio 8 でサポートする Solaris オペレーティング環境のバージョンごとに SUNWlibC パッチが用意されています。このパッチは、コンパイルに使用するシステムだけでなく、作成されたプログラムを稼動させるすべてのシステムにインストールする必要があります。これらのパッチをインストールしないと、一部のプログラムがリンクされなかったり、実行時エラーで異常終了したりすることがあります。たとえば、リンカーから次のようなメッセージが報告されることがあります。

    Undefined symbol First referenced in file
    std::basic_ostream<char,std::char_traits<char> >&operator<<(td::basic_ostream<char,std::char_traits<char> >&const RWCString&) test.o 
        ld: fatal: Symbol referencing errors. No output written to test

    次のようなエラーメッセージが返されることもあります。

        
   [ヒント: クラスの、インライン化されておらず、純粋でない 1 つ目の
    仮想関数が定義されているか確認してください。]

    今回リリースされた Sun ONE Studio 8 の必須パッチとオプションパッチについては、『Sun ONE Studio 8 リリースノート』を参照してください。 リリースノートは、Sun ONE Studio 8 CD の /cdrom/ml_devpro_v10n1_sparc/docs/ja/release_notes_ja.html に HTML 形式で含まれています。 リリースノートは、Sun ONE Studio 8 Web サイトのマニュアル索引ページ http://sun.co.jp/software/sundev/suncc/documentation から入手できます。

  5. コンパイラのバージョン間の互換性の問題

    ここでは、C++ コンパイラバージョン 4.0、4.1、4.2 と次に示すバージョン間の互換性の問題について説明します。

    • Sun WorkShop C++ (5.0) コンパイラ
    • Forte Developer 6 C++ (5.1) コンパイラ
    • Forte Developer 6 update 1 C++ (5.2) コンパイラ
    • Forte Developer 6 update 2 C++ (5.3) コンパイラ
    • Forte Developer 7 (5.4) コンパイラ
    • Sun ONE Studio 8 (5.5) コンパイラ
    1. キャッシュバージョンの違いによるコンパイルエラー
    2. C++ インタフェースの互換性の問題
    3. Tools.h++ の使用
    4. 複数のテンプレートリポジトリの使用 -ptr オプションが無視される
    5. const メンバー関数のポインタを含む 4.0.1 ライブラリとのリンク
    6. 以前のコンパイラでコンパイルしたライブラリとのリンク
    7. 異なるバージョンで生成されたオブジェクトコードの混在
     
     
    1. キャッシュバージョンの違いによるコンパイルエラー

      コンパイラを変更するときは、必ず SunWS_cache サブディレクトリを含むすべてのディレクトリに対して CCadmin -clean を実行してください (rm -rf SunWS_cache でも可)。この操作を行わないと、次のようなコンパイルエラーが発生することがあります。

      • SunWS_cache: Error: Database version mismatch
        <path>/SunWS_cache/CC_version.

      • "<path>/SunWS_cache/CC_state",
        line 3: Error:"" not allowed here. ** Assertion ** : 0


    2. C++ インタフェースの互換性の問題

      バージョン 5.0、5.1、5.2、5.3、5.4、および 5.5 の C++ コンパイラとバージョン 4.0、4.1、および 4.2 の C++ コンパイラとの間にバイナリレベルの互換性はありません (5.0、5.1、5.2、5.3、5.4、5.5 のコンパイラによるコンパイル時に -compat オプションを使用した場合を除く)。これは、ANSI/ISO C++ 規格に定義されている仕様に合わせて、クラスの配置や呼び出しの順序、名前の符号化方法が変更されたことが原因です。

      バージョン 5.0、5.1、5.2、5.3、5.4 および 5.5 の C++ コンパイラはレベルの互換性があります。

      詳細は、『C++ 移行ガイド』を参照してください。このマニュアルの HTML 版にアクセスするには、ブラウザで file:/opt/SUNWspro/docs/ja/index.html を開きます。

    3. Tools.h++ の使用

      C++ コンパイラは、デフォルトで標準の iostream を使用します。 Tools.h++ を標準モードで使用する場合は、-library=rwtools7_std オプションを使用するか、または次に示すように、コンパイラオプションに libiostream 指定する必要があります。

      example% CC -library=rwtools7_std foo.cc -> 標準の iostreams を使用
example% CC -library=rwtools7,iostream foo.cc -> 従来の iostreams を使用

      ただし、(-compat コンパイラオプションを使用した) 互換モードでは、標準ライブラリが使用できないため、-library=rwtools7_std を指定することはできません。

      example% CC -compat foo.cc -> 互換モードでは標準ライブラリを使用できない

      -library=rwtools7、-library=rwtools7_dbg、-library=rwtools7_std、また-library=rwtools7_std_dbg を -library=stlport4 とともに使用しないでください。Tools.h++ は STLport ではサポートされていません。

      -library=rwtools7_std オプションと -library=rwtools7,iostream オプションで生成されたバイナリ間に互換性はありません。これらのオプションのどちらか一方を使用する場合は、ソースファイルもすべて同じオプションでコンパイルする必要があります。

      また、『C++ 移行ガイド』も参照してください。このマニュアルの HTML 版にアクセスするには、ブラウザで file:/opt/SUNWspro/docs/ja/index.html を開きます。

    4. 複数のテンプレートリポジトリの使用 -ptr オプションが無視される

      5.0 より前の C++ コンパイラでは、-ptr オプションを使用して、テンプレートのインスタンス化に使用するリポジトリを指定していました。 バージョン 5.0、5.1、5.2、5.3、5.4、および 5.5 の C++ コンパイラでは、-ptr オプションは不要です。これは、コンパイルシステムが、読み取るオブジェクトファイルに対応するテンプレートリポジトリに含まれているテンプレートインスタンスを、CC コマンドで指定された出力先ディレクトリ内のリポジトリに書き込むためです。

      今回のリリースで、-ptr オプションは廃止されており、コンパイラはこのオプションを無視します。オプションは無視されるとしても、すべてのコンパイルコマンドから -ptr は削除しておいてください。その理由は、今後のリリースで、別の動作を行う -ptr が再実装される可能性があるためです。

      注 -- 複数のアプリケーションやライブラリの間で 1 つのテンプレートリポジトリを共有することは、以前からできません。共有しようとすると、コンパイルが正しく行われないことがあり、その場合は、テンプレートが再定義されて、実行時に予測できない結果が生じます。詳細は、『C++ ユーザーズガイド』を参照してください。

    5. const メンバー関数のポインタを含む 4.0.1 ライブラリとのリンク

      C++ 4.0.1 コンパイラが const メンバー関数のポインタに対して生成する符号化名は、バージョン 4.1、4.2、5.0、5.1、5.2、5.3、5.4、および 5.5 のコンパイラが生成する内容とは異なります。C++ コンパイラを使用していて、4.0.1 で構築された、符号化名を含むライブラリとリンクできない場合は、そのライブラリを再コンパイルするか、-compat -Qoption ccfe -abirel=4.0.1 フラグを指定して、プログラムの残り部分をコンパイルする必要があります。

      注 -- 将来のリリースでは -abirel=4.0.1 フラグのサポートが廃止される可能性があります。

    6. 以前のコンパイラでコンパイルしたライブラリとのリンク

      C++ 4.0.1 および C++ 4.1 コンパイラでは、extern 「C」関数でインスタンス化されたテンプレートに対して、解析不可能な符号化名が生成されていました。したがって、デバッグツールが正しく動作しませんでした。この問題は解決されましたが、一部ユーザーから、バージョン 5.0、5.1、5.2、5.3、5.4、および 5.5 の C++ コンパイラでコンパイルしたオブジェクトを旧バージョンのコンパイラでコンパイルしたライブラリとリンクできないとの報告があります。 この問題はまれにしか発生しませんが、発生した場合は、次のどちらかを行なってください。

      • Sun ONE Studio C++ (5.5) コンパイラを使用してライブラリを再コンパイルするか、あるいは
      • -compat および -Qoption ccfe -abirel=4.1 フラグを使用して、Sun ONE Studio 8 C++ (5.5) コンパイラで新しいオブジェクトをコンパイルする。

      注 -- 将来のリリースでは -abirel=4.1 フラグのサポートが廃止される可能性があります。

    7. 異なるバージョンで生成されたオブジェクトコードの混在

      互換モードと標準モードのコードを混在させていない限り、異なるバージョンの C++ コンパイラで生成したオブジェクトコードを同じプログラムに混在させることができます。ただし、最終プログラムのリンクには、混用されているコンパイラの中で最新のバージョンを使用する必要があります。

      注 -- バージョン 4.2 で生成したコードと標準モードの C++ コードをリンクすることはできません。

 

G. 記述の誤りの訂正 

C++ コンパイラマニュアルの旧版には、以下の記述誤りがありました。

H. ライブラリの再配布について

 

I. 未対応の言語仕様

 

Copyright © 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.