E. よくある質問

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. その他の注意事項
   • RWCString と RWWString のサイズは、clone メンバー関数を使用して変更できます。aString.clone(0) を使用すると、String のサイズがちょうど十分な大きさになるように調整されますが、aString.clone(aString.length()+someMore) 使用すると、someMore で指定したバイト数の領域がバッファ内に余分に確保されます。全反復子共通:コレクションを直接変更するか、関係する反復子以外のすべての反復子を使用して変更した場合、その反復子の有効性は保証されなくなります。「大体の場合」はこのような副作用なしに変更できるコレクションもありますが、コレクションの変更後も反復子が信頼できることを全面的に期待すると、予想外の問題が発生する可能性があります。ご注意ください。
     
     
   • 一部のテンプレート化されたコンテナには、clearAndDestroy() メソッドがありますが、このメソッドにはコンテナが同一オブジェクトへのポインタを複数保持してしまうことへの保護機構が組み込まれていません。コンテナが重複したポインタを保持している可能性がある場合は、clearAndDestroy() は呼び出さないでください。(RWCollections には当てはまりません。)
     
     
   • 一部の Tools.h++ メソッドは多重定義されて、ポインタ型と整数型のどちらでも受け取れるようになっています。たとえば、RWTime コンストラクタには、構造体へのポインタ (struct tm* ) と、「時間の始まり」以降の秒数を表す整数値 (unsigned long) のどちらでも渡すことができます。このようなメソッドにゼロを渡そうとすると、コンパイラは正しく「あいまいさ」であることを示すメッセージを返します。 この問題は、ゼロ値を適切なデータ型の変数に格納するか、キャスト (型変換) するか、"0ul" などのように定数の型を明示的に指定することによって解決できます。
     
     
   • struct tm* からの不正な RWTime の作成の問題:システム関数 localtime() は static struct tm へのポインタを返します。その後さらに localtime を呼び出すと、この構造体が上書きされます。RWTime は RWZone::local() が必要になると作成します。この作成でも localtime() が呼び出されます。localtime() の呼び出しに関連する問題が生じた場合は、localtime() を最初に呼び出す前に RWZone::local() への呼び出しを行なってください。
     
     
   • RWLocale::asString(struct tm*, ..%U.., RWZone&= RWZone::local()) は、日曜日から始まる年の第何週かを示す値について、プラットフォームによって異なる値を返します。標準は存在しますが、多くの実装が準拠していません。Rogue Wave は結果を検査しないで、そのまま渡すため、プラットフォーム間の結果の相違が問題になる場合は、%U 書式指定子を使用しないでください。
     
     

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © 2003 Sun Microsystems, Inc. All rights reserved. ライセンス条件に従って使用されるものとします。