                                                更新日付: 2004 年 3 月 23 日

 Sun[tm] Studio 9:Tools.h++ 7.1.0 Readme


  ------------------------------------------------------------------------
 注 - この Sun Studio 9 リリースでは Tools.h++ に変更はありません。
      節 A から F を通して Forte Developer 7 Tools.h++ 7.1.0 Readme からの
      変更はありません。
  ------------------------------------------------------------------------

 目次

   A. はじめに
   B. ソフトウェアの修正事項と新機能
   C. 問題点と回避策
   D. 制限事項と互換性の問題
   E. 記述の誤りの訂正
   F. FAQ

  ------------------------------------------------------------------------

 A. はじめに

 この文書は、Tools.h++ バージョン 7.1.0 についての最新情報です。記載内容は、
 今回のリリースで対処したソフトウェアの修正事項、既知の問題点、制限事項、
 互換性の問題等です。この Readme は、Tools.h++ の 1999 年 9 月現在の 
 バージョン 7.1.0 とそれ以前のバージョン (該当する場合は注記しています) 
 を対象とします。

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

     example% more /opt/SUNWspro/READMEs/ja/Tools.h++

 この文書の HTML 版にアクセスするには、Netscape(TM) Communicator 4 または互換
 バージョンの Netscape ブラウザから、次のファイルを開きます。

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

 注 - Sun Studio ソフトウェアが /opt 以外のディレクトリにインストールされて
      いる場合は、システム管理者に実際のパスをお尋ねください。


  ------------------------------------------------------------------------

 B. ソフトウェアの修正事項と新機能

   1. 夏時間規則を導出する新しい静的関数: RWZone::os()

      新しい静的関数 RWZone::os() は、zone.cpp に追加されています。この関数を
      呼び出すと、基本システムから現在の夏時間規則を導出します。
      RWZone::local(RWZone::os () ) をインスタンス化すると、当年度の夏時間
      規則を設定します。

   2. RWXDRi(o)stream のバグ修正 (7340):XDR ストリームは IRIX 上で 64 ビットを
      サポートしています。

   3. RWTime bug(9194) のバグの修正:time_t から RWTime に戻しました。

   4. RWCRExpr bug(11049) のバグの修正:閉じていない括弧リストをコンパイルする
      ときの無限ループが解決されました。

   5. RWCRExpr の問題の解決: 括弧式内の開く括弧の直後にキャレット "(^" が
      見つからなかった場合に無効な状態になっていました。

   6. RWCRExpr のバグの修正: 文字列内の最も長いパターンにマッチしませんでした。

   7. インデックスが無効な場合に、テンプレート化されたベクトルの removeFirst()
      メソッドから Boundary Error が送出されるようにしました。

   8. RWT***OrderedVector に "operator=="、また、RWT***SortedVector に 
      "operator<" を追加して、標準 C++ ライブラリを利用しなくても、これらの
      クラスを再帰的にインスタンス化できるようにしました。

  ------------------------------------------------------------------------

 C. 問題点と回避策

 ここでは、今回のリリースを発表する前に解決できなかった問題点とそれらの問題に
 対する回避策を説明します。

   1. スレッド対応バージョンのライブラリで、RWCString コンストラクタの処理速度
      が非常に低下します。ただし、この問題は大部分のユーザーには影響ありません。

   2. テンプレートコレクションクラスのメンバー関数のいくつかについて、
      T ではなく const T & を返すように変更しました。
      メソッド間のオブジェクトのコピーに生じるオーバーヘッドを回避できること
      から、この変更は成功と言えます。ただし、一部のケースで、コードが正常に
      機能しません。すなわち、const のデータ型に伴う問題を避けるためにオブジェ
      クトのコピーを取り込むようにしているコードでは、現在使用している非 const
      メソッドが const 参照で機能しないことがあります。最良の解決方法は、正しく
      const されるようにコードを書き換えることです。

   3. 演算子の<<、>> を vstream と組み合わせて使用する RWBoolean およびブール型
      (bool) を持続するときの問題。コンパイラが bool を「実数型」としてサポート
      している場合、RW_NO_BOOL は未定義、RWBoolean はブール型に型定義されます。
      ただし、ブール型へのポインタの変換は標準の変換であるため、RWBoolean
      (bool) を vstream から抽出、または vstream に挿入する目的で演算子 >> と
      <<を使用している場合、たとえば、次のコードをコンパイルする場合、コンパイラ
      は次の 2 つの違いを判断できないというメッセージを出力します。

       RWpostream::operator<<(RWBoolean)

      (たとえば)

       operator<<(RWVostream&, const RWCollectable*)

      次のようなコードをコンパイルする場合、

       anRWpostream << aDerivedCollectable*

      (コンパイラが判断できない理由は、どちらの場合も、引数の一方は完全に一致
      するのに、もう一方は組み込み変換を必要とするため、どちらを選択しても同じ
      程度の妥当性があるためです。)

      この問題は、Tools.h++ の仮想ストリームを再設計することで対処できますが、
      このために必要な変更によって、現状のコードのリンク互換性が損なわれるため 
      (同時に、一部ユーザーにとっては、コードの互換性さえ維持できなくなるため)、
      解決が先送りになっています。代替措置として、サンでは、bool 用に多重定義
      された挿入演算子と抽出演算子を削除しています。この制約は vstream 階層の
      put() メソッドおよび get() メソッドには適用されないため、多重定義された
      演算子を使わずに、これまでどおり RWBoolean (bool) を持続できます。

      この問題を発生させるコンパイラは、vstream にブールを挿入するとき、表示を
      しないでブールを他のデータ型に変換します。このため、次のようなコードも
      一見正しく動作します。 

       aPostream << FALSE << " or " << TRUE;

      ただし、対応するエクストラクタは失敗します。

       aPistream>> oneRWBoolean << aString << anotherRWBoolean;

      さらに、このようなコンパイラの中には、このようなケースでまったく不適切な
      診断を下し、「oneRWBoolean と anotherRWBoolean を const int 参照に変更
      するように」という内容のメッセージを出力するものが少なくとも 1 つはあり
      ます。ブールを vistream から抽出するときの問題であることを示唆する診断が
      コンパイラから出力された場合は、抽出コード (コンパイラによって指示されて
      いる) だけでなく挿入コードにも次の修正を適用する必要があります。適用しな
      いと、挿入バイト数が、ストリームから get() で取り出す数と一致しなくなりま
      す。具体的には、次のようにコードに書き換えます。 

       aVostream << anyBoolean;

      上のコードを次のように書き換えます。

       aVostream.put(anyBoolean);

      および

       aVistream >> anyBoolean;

      上のコードを次のように書き換えます。

       aVistream.get(anyBoolean);

      これらの修正は、修正を必要とするクラスの rwSaveGuts および rwRestoreGuts
      の本体、および RWCollectable から派生する独自のクラスの saveGuts および
      restoreGuts メソッドで行います。

  ------------------------------------------------------------------------

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

 ここでは、各種制限事項やシステムおよび他のソフトウェアとの互換性の問題に
 ついて説明しています。最新情報については、http://docs.sun.com/ から入手
 可能なリリースノートを参照してください。

  ------------------------------------------------------------------------

 E. 記述の誤りの訂正

   1. 内部クラスの問題

      Tools.h++ による内部使用のみを目的として開発されたクラスの一部が、マニュ
      アルの「クラス階層」に記載されていて、「クラスリファレンス」には記載され
      ていません。それらのクラスは意図的に省略されたもので、記載されていないク
      ラスは、将来のリリースでユーザーに通知することなく変更、拡張、削除される
      可能性があります。それらのクラスは使用しないでください。

   2. RWFactory

      「クラスリファレンス」で紹介されている RWFactory の使用例は誤りです。次の
       コード例は間違っています。

       RWBag* b = (RWBag*)getRWFactory()->create(__RWBAG);

      正しくは、次のようになります。

       RWBag* b = (RWBag*)rwCreateFromFactory(__RWBAG);

   3. RWTPtrSlistIterator

      RWTPtrSlistIterator の「クラスリファレンス」の説明に誤りがあります。正しく
      は、「slist を変更すると、反復子が有効でなくなります」です。これは、一般に
      、すべての反復子についてもいえます。

   4. テンプレート化された辞書コンテナに格納されている値

      テンプレート化された辞書コンテナに格納されている値は、operator==() および
      operator<() に応答しなければなりません。この機能は、規格の仕様に従って、
      標準 C++ ライブラリを実装クラスとして使用する場合や、同じキーであっても
      値の異なるコンテナが正しく区別されるよう、独自の実装を行っている場合に
      必要です。ANSII/ISO 規格の草稿によると、コンパイラは、これらの演算子を
      使用される場合のみ要求する必要があります。残念ながら、一部のコンパイラは、
      この規格草稿に適応していません。

   5. マニュアルの operator== に関する記述

      マニュアル内のテンプレートコレクションをインスタンス化する型の意味の説明
      に、「クラス K は、十分に定義された等価の意味の解釈 (K::operator==(const 
      K&)) を持たなくてはならない」という意味の記述があります。この例は限定的す
      ぎます。正確には、「コンパイラは、演算子の実装状態に関係なく、K の 2 つの
      インスタンスに適用される operator== を確実に見つけることができなくては
      ならない」です。

   6. RW_CENTURY_REQD

      RW_CENTURY_REQD は、"x" フォーマットの asString が西暦を 4 桁で出力するよ
      うにします。asString はデフォルトで "x" フォーマットオプションを選択する
      ため、西暦の 4 桁表示もデフォルトになります。オペレーティングシステムが
      管理している他のフォーマットオプションが、この影響を受けることはありませ
      ん。

   7. RWLocaleSnapshot

      RWLocaleSnapshot に関する次の説明が、マニュアルに記載されていませんでし
      た。

      注 - RWLocaleSnapshot クラスのコンストラクタは、スレッドに対して安全では
           ない setlocale 関数を呼び出します。マルチスレッド環境で問題が起きない
           ようにするには、他のどのスレッドもロケール依存関数を使用しないことが
           保証できるときにだけ、RWLocaleSnapshot のインスタンスを作成してくだ
           さい。この条件を保証するために、初期スレッドで RWLocaleSnapshot の
           すべてのインスタンスを作成してから、その他のスレッドを起動します。
           新しい情報は、現時点ではありません。

  ------------------------------------------------------------------------

 F. FAQ

   1. Rogue Wave Software と連絡を取りたいのですが。

      Rogue Wave からサン製品のサポートを受けることはできません。その他の Rogue
      Wave 製品に関する情報は、次のどちらかの電話番号に電話してください。

      1-541-754-3010 または
      1-800-487-3217

   2. Tools.h++ のサポートを受けたいのですが。

      その他のサン製品同様、サンのサポートをご利用ください。 サンは、Rogue Wave
      からアップデートやコンサルティングサービス、修正を受けていますが、
      Tools.h++ を完全にサポートしています。

   3. サンのバージョンと Rogue Wave のバージョンは別ですか。

      Tools.h++ のサンと Rogue Wave のバージョンは、同じソースをもとに作成されて
      います。問題の修正はマスターソースにも 反映されます。ただし、それぞれ独自
      のスケジュールでリリースしているため、リリースされたバージョンには若干の
      相違があることがあります。一般に、より頻繁にリリースされるため、常にという
      わけではありませんが、Rogue Wave の方がサンよりバージョンが少し進んでいる
      ことがあります。

      サンではマイナーリリース全般にわたってリンク互換性を維持していて、特定の
      修正がリンク互換性に影響を与える場合は、修正を控えることがあります。リンク
      互換性を維持することによって、新しい Tools.h++ ライブラリを旧 Tools.h++ 
      ライブラリでコンパイルしたオブジェクトファイルにリンクできます。

   4. 最新の Rogue Wave バージョンをサンから入手できますか。

      サンが最新の Rogue Wave バージョンを同時出荷する場合を除き、通常はできま
      せん。重大なプログラム修正があった場合、サンから同時期に入手できることも
      あります。

   5. Tools.h++ ヘッダーファイルはどこにありますか。

       example% CC -H <ファイル>.cc

      を使用して、インストールディレクトリ内の Tools.h++ ヘッダーファイルの格納
      場所を確認できます。

   6. libwtool の共有ライブラリ版はありますか。

      Tools.h++ 7 用の共有ライブラリ版があります。

   7. Tools.h++ を利用するライブラリを構築しても問題ありませんか。

      作成手順を簡単にするなどの目的で、Tools.h++ に依存するアーカイブライブラリ
      をプロジェクト内で内部的に構築することは、まったく問題がありません。
      自分のアーカイブライブラリを他のユーザーに渡す場合は、そのユーザーも 
      Tools.h++ の正規ユーザーである必要があります。サン製品の顧客は 
      librwtool.so.2 を再頒布できますが、付属するヘッダーファイルは頒布できま
      せん。

      詳細は、<install-directory>/READMEs/ja/runtime.libraries を参照してくだ
      さい。

   8. dbx から RWCString を出力するには、どうしたらいいですか。

      Sun WorkShop では、dbx のコマンドインタプリタは Korn シェルです。このため
      、特化したデバッグ機能を持つ新しい dbx コマンドを定義できます。文字列の
      出力はよく必要とされる機能です。dbx で文字列を出力する方法については、
      Tools.h++ マニュアルのコンパイルとデバッグに関する章を参照してください。
      RWCString を出力するもう 1 つの方法として、次のような新しい dbx コマンドを
　　　定義することもできます。

       function dumpstr { print (char*)($1.pref_+1) }

      この関数があると dbx で次の定義が実行できます。

       (dbx) dumpstr myString (char *) (myString.pref_+1) = 0x28d5c "Contents of
        myString" (dbx)

      dumpstr の定義を .dbxrc に書き込むこともできます。

   9. その他の注意事項
         o RWCString と RWWString のサイズは、clone メンバー関数を使用して変更
           できます。aString.clone(0) を使用すると、String のサイズがちょうど
           十分な大きさになるように調整されますが、
           aString.clone(aString.length()+someMore) 使用すると、someMore で指定
           したバイト数の領域がバッファ内に余分に確保されます。全反復子共通:
           コレクションを直接変更するか、関係する反復子以外のすべての反復子を
           使用して変更した場合、その反復子の有効性は保証されなくなります。
           「大体の場合」はこのような副作用なしに変更できるコレクションもあり
           ますが、コレクションの変更後も反復子が信頼できることを全面的に期待
           すると、予想外の問題が発生する可能性があります。ご注意ください。

         o 一部のテンプレート化されたコンテナには、clearAndDestroy() メソッドが
           ありますが、このメソッドにはコンテナが同一オブジェクトへのポインタを
           複数保持してしまうことへの保護機構が組み込まれていません。コンテナが
           重複したポインタを保持している可能性がある場合は、clearAndDestroy() 
           は呼び出さないでください。(RWCollections には当てはまりません。)

         o 一部の Tools.h++ メソッドは多重定義されて、ポインタ型と整数型のどちら
           でも受け取れるようになっています。たとえば、RWTime コンストラクタに
           は、構造体へのポインタ (struct tm* ) と、「時間の始まり」以降の秒数を
           表す整数値 (unsigned long) のどちらでも渡すことができます。このような
           メソッドにゼロを渡そうとすると、コンパイラは正しく「あいまいさ」で
           あることを示すメッセージを返します。この問題は、ゼロ値を適切なデータ
           型の変数に格納するか、キャスト (型変換) するか、"0ul" などのように
           定数の型を明示的に指定することによって解決できます。

         o struct tm* からの不正な RWTime の作成の問題:システム関数 localtime()
           は static struct tm へのポインタを返します。その後さらに localtime を
           呼び出すと、この構造体が上書きされます。RWTime は RWZone::local() が
           必要になると作成します。この作成でも localtime() が呼び出されます。
           localtime() の呼び出しに関連する問題が生じた場合は、localtime() を
           最初に呼び出す前に RWZone::local() への呼び出しを行なってください。

         o RWLocale::asString(struct tm*, ..%U.., RWZone&= RWZone::local()) は、
           日曜日から始まる年の第何週かを示す値について、プラットフォームに
           よって異なる値を返します。標準は存在しますが、多くの実装が準拠して
           いません。Rogue Wave は結果を検査しないで、そのまま渡すため、プラット
           フォーム間の結果の相違が問題になる場合は、%U 書式指定子を使用しないで
           ください。

         o RWFactory の使用と多相持続性の問題:ファクトリ (Factory) によって 
           RWCollectable を作成するには、その前にそのコレクタブル (Collectable)
           とその識別子が登録されている必要があります。このためには、プログラム
           の中で、その RWCollectable のインスタンスを少なくとも 1 つ作成します
           。

           この問題はさまざまな形で現れます。通常は次のメッセージが表示されます
           。

           "[NOCREATE] RWFactory: no create function for class with ID 
           (something)"

           ただし、場合によっては theFactory->create(someID) の呼び出し時にコア
           ダンプや GPF が発生する可能性もあります
           (この呼び出しは、持続性がある RWCollectable の読み取り中に行われます)
           。この現象は、オブジェクトへのポインタだけをインスタンス化した場合に
           、そのオブジェクトそのもののインスタンスを作成しないコンパイラで、
           発生することがあります。

         o 独自の RWCollectable を作成するときは、その独自クラスに、
           RWCollectable メソッドが使用するすべてのメソッドを用意することが重要
           です。特に、持続性機構が「満たす」ことができる新しい「空の」インスタ
           ンスを作成するためのデフォルトのコンストラクタと、オブジェクトの
           コピーを新しい場所に作成するためのコピーコンストラクタを用意する必要
           があります。また、関連のあるメソッドと演算子が互いに矛盾しないよう
           注意する必要もあります。たとえば、そのクラスに比較演算子を定義する
           場合は、それらの演算子から、compareTo() が返す値と一致する結果が返さ
           れるようにします。

         o RWCollectable::recursiveStoreSize() と 
           RWCollectable::binaryStoreSize() を使用するタイミング:答えは単純です
           が、若干の考慮が必要になることがあります。 operator<<() 、またはマニ
           ュアルに記載されていない recursiveSaveOn() メソッドを使用する場合は、
           RWCollectable の「一番上の」レベルで recursiveStoreSize() を使用すべ
           きです。これに対し、binaryStoreSize() は、コレクション全体の「一部」
           を操作する場合 (つまり、saveGuts() を使用する場合) に使用します。

           どちらのメソッドもストリームの操作は行いません。両方とも RWFile に対
           してのみ使用可能です。仮想ストリームに 保存された形の RWCollectable 
           のサイズを調べる場合は、クラス RWAuditStreamBuffer を使用してください
           。

         o メインの前に相互排他ロックを使用すると、静的初期化の順序を知ることが
           困難であること (一般的な解決策なし) と、特定の相互排他ロックをメイン
           の前のどのスレッドが初期化すべきかを知ることが困難であるという対の
           問題が発生します。現在のところ、この問題に対するソフトウェアによる
           解決方法はありません。このため、静的初期化コードを使用して「スレッド
           活用」関数を呼び出すのは避けてください。

         o 独自クラスにおけるテンプレート化されたハッシュベースのコンテナの使用:
           デフォルトでないコンストラクタ (たとえば、Tools.h++ のハッシュベース
           コンテナ) を必要とするクラスメンバーをユーザー独自のクラスに追加する
           方法について、多くのユーザーから問い合わせがありました。このためには
           、「メンバー初期化」と呼ばれる特殊な構文を使用してください。たとえば
           、次のハッシュ辞書メンバーが独自クラスに存在すると仮定します。

             class MyClass {
               // ...
               RWTValHashDictionary<RWCString,int> myDict; // no ctor args here!
            public:
            MyClass();
            };

           メンバの初期設定は次のようになります:
           実際のコンストラクタの本体を提供する場所では ":" を使用する必要があり
           ます。その後、デフォルト以外のコンストラクションを必要とする各メンバ
           のコンストラクタをコンマで区切ったリストを配置します。次の例は上記の
           例に基づいています。

            MyClass::MyClass() :myDict(theHashFunction) /* このように指定 */ { /* 独自のコンストラクタ用のコード */ }

           もちろん、ケースによっては、この代わりにメンバー初期化構文を使用して
           インラインのコンストラクタを書くこともできます。ただし、クラス宣言内
           の辞書の「宣言」にコンストラクタ引数を追加することはできません。

  ------------------------------------------------------------------------

 Copyright (C) 2004 Sun Microsystems, Inc. All rights reserved. 
 Use is subject to license terms.

