問題タブ [opaque-pointers]

私は現在、カプセル化の標準的な手法として不透明なポインターを使用していますが、OpenGL API を見ると、id 番号を使用する方が良い選択である可能性があると思います。ベテランの C プログラマーからのアドバイスをお願いします (この言語を積極的に使用してから 2 年ほどしか経っていません)。

確認または修正したい私の最初の考えは次のとおりです。

ID 番号の考えられる利点:

• ID番号を使用する場合、実装でオブジェクト/メモリプールを使用するのはかなり簡単です

• ID 番号はシステム メモリにマップする必要はありません (GL の場合はグラフィックス メモリを参照できます)。

ID 番号の考えられる短所:

• 実装が少し複雑になります

共有ライブラリを使用する状況を考慮した同様の質問があります: 不透明なオブジェクトに整数 ID またはポインターを使用する必要がありますか? 私の質問は共有ライブラリに関するものではなく、ユーザー コードから実装の詳細を隠す一般的なケースに関するものです。

MyObjectHandle を typedef して、ライブラリが ID 番号と不透明なポインターを切り替えることができると思います。

問題は 、不透明なポインターと C プログラミング言語を使用した ID 番号の長所と短所は何ですか?

この研究により、CoreFoundation CGColor オブジェクトの内部が理解できることを願っています。IOS宣言と一致するように見える無料のクォーツプロジェクトからCGColor構造体のサンプル定義を見つけることができました(私の研究に依存しています)。

(colorID フィールドは、フリークォーツでは nextID と名付けられていますが、IOS による色の一意の識別子として意図されていると思いますので、次の識別子のようなものではありません。)

グローバルにスレッド セーフな一意の値が保持され、CGColor オブジェクトが作成されて colorID メンバーに割り当てられるたびに 1 ずつ増加します。ドキュメントに記載されていない CGColorGetIdentifier() 関数のみがこの値を返します。(単調に増加する id 値について推測しています。デバイスとキャリブレーションされたカラー ルックアップの間、またはその逆の変換中にパフォーマンスが向上する可能性があります。)

CoreGraphics とそのリソース ライブラリを確認しました。ripc_GetColor (libRIP.A.dylib) 関数だけが CGColorGetIdentifier() 関数を呼び出すことがわかりました。

CGColorGetIdentifier; のコール スタック (colorID に関する推測に役立つことを期待して)

現在のカラー グラフィックス コンテキスト操作では、ripc_GetColor() は現在のストローク/塗りつぶしの色の変換を計算し、この色の参照と colorID を使用してこれらの変換をキャッシュします。

したがって、次のグラフィックス コンテキスト操作では、ripc_GetColor() は、以前にキャッシュされた参照と現在の参照および colorID の値を比較して、最後のグラフィックス コンテキスト操作で既にキャッシュされた色変換をスキップします。

解放されたオブジェクトの参照 (メモリ アドレス) は、別のオブジェクトの作成中に使用できることがわかっています。したがって、参照を確認するだけでは、同じ色のオブジェクトが有効であることを確認するのに十分ではなく、内容または何らかのハッシュ値を比較する必要があります。したがって、この目的のために一意の識別子の値を使用できます。

ただし、識別子は単一のオブジェクトとその参照に使用されている可能性があるため、ID のみを比較するだけで十分です。ただし、ref と id の両方が使用されます。このような単純で重要なことを見落としていたとは思えません。

したがって、id と ref の両方を比較する必要性を見つけようとしますが、id だけを比較するだけで十分です。

以前のアプローチから残っているので、完全に放棄することはできませんでしたか?

私が作成したライブラリのメイン クラス ヘッダーにサード パーティのファイルが含まれていることを、それをリンクする実行可能ファイルから隠そうとしています。つまり、次のとおりです。

クラス A を定義するライブラリを作成しました。クラス A はクラス B (サード パーティのライブラリで定義されています) から継承します。例：

クラス B のヘッダー ファイルは、私のライブラリにとって理想的な環境にいくつかの変更を加えますが、私のライブラリをリンクする実行可能ファイルには有害です。誰かが私に潜在的な解決策として不透明なポインターを指摘しましたが、それらを使用して「B」を非表示にする方法がわかりません。

Bh が含まれていることを隠す方法を知っている人はいますか? 解決策として、C++11 は問題ありませんが、追加の依存関係 (boost など) へのリンクはオプションではありません。

いくつかの不透明な型があり、Core Foundation を模倣する参照カウント セマンティックを実装しました。これは、clangが半有効な潜在的なリークについて警告することを除いて、十分に機能します。

私はattribute_cf_consumed自分のバージョンを作成するようなものや簡単な方法を探しています。

参考までに、これは私が現在警告を黙らせる方法です。それは機能しますが、私の意見では、警告をそのままにしてifおくのと同じくらい悪いです。MytypeReleasefree

次の例では、~CImpl が正しく呼び出される可能性があるのに、クラスを移動する必要があるときに、コンパイラが不完全な型を持っていると言うのはなぜでしょうか?

Impl の宣言をヘッダーに移動すると機能するのですが、なぜデストラクタが正常に呼び出されるので、型が不完全ではないように見えますが、移動すると問題が発生します。

ファイル: C.hpp

ファイル C.cpp

ファイル: main.cpp

コンパイラ出力:

main.c

stackg.h

上記のプログラムは GCC コンパイラで正常にコンパイルされますが、MSVC2008 では次のエラーが発生します。

コードを何も変更せずにプログラムをコンパイルするには、MSVC に何を指示すればよいですか?

編集

stackg.h::の 8 行目でエラーが発生しますtypedef struct stack_gt* stack_gt;

編集 2

他に何もないなら、私は一緒に行きますtypedef struct _stack_gt* stack_gt;

私は現在、ユーザーが不透明なポインターを渡すことができるようにする API を設計しています。このポインターは、後で実装する必要があるインターフェイスのメソッドが呼び出されたときに返されます。

これは基本的に次のようになります。

API 側:

ユーザー側:

そのシナリオで不透明なポインターを定義する最良の方法は何ですか?

基本的に typedef struct _CustomContext* CustomContext; 、未定義の（前方宣言された）構造体へのポインターを定義するものを考えました。

typedef struct {} * CustomContext; しかし、名前のない構造体へのポインターを定義するのはどれが良い代替策になるかどうかも疑問に思って いましたか? 私が見る主な問題は、異なる翻訳単位に含まれている場合、異なる構造体を定義する可能性があることです。それは正しいですか？

void*もちろん、型の安全性の問題からa は使いたくありません。

OS ごとに異なる実装を持つ同期両端キューを作成しようとしています (たとえば、std:: Android、Windows、Linux などのミューテックスと条件変数 - sync_deque_stl.cpp での実装、iOS/ でのグランド セントラル ディスパッチ)。 MacOS - sync_deque_gcd.cpp での実装)。また、gyp を使用してプロジェクトを生成しています。

1. 次の定義を持つ sync_deque.hpp ファイルがあります。

   /li>

2. 次に、gyp を使用して以下を作成します。

   • sync_deque_gcd.cpp を含める MacOS/iOS 上の Xcode プロジェクト。ただし、sync_deque_stl.cpp は含めません。
   • sync_deque_stl.cpp を含めるが、sync_deque_gcd.cpp を含めない Windows 上の Visual Studio プロジェクト
   • (基本的に、各OSはsync_dequeの独自の実装.cppを取得しますが、ヘッダーファイルはOS間で共通です)

3. .cpp ファイルでは、c++ 型のエイリアシングを使用します (例は sync_deque_stl.cpp から取得):

   /li>

これは有効な C++11 構文ですが、 sync_deque.hpp の前方宣言と競合します。

sync_deque_stl.cpp:29:1: エラー: opaque_sync_deque = sync_deque_stl を使用して、別の種類のシンボルとして「opaque_sync_deque」を再定義しました。

このセットアップ (すべての OS で共有される .hpp 内の不透明なテンプレート タイプと関数シグネチャ + 異なる OS 用の個別の .cpp ファイル内の実装) を維持し、コンパイルすることは可能ですか? /gcd と /stl を個別に作成し、各ディレクトリに個別の sync _deque ヘッダー ファイルを作成し、gyp を使用して適切なヘッダー ファイルを選択することもできますが、sync_deque.hpp を 1 つだけ作成する方が簡単です。どんな助けでも大歓迎です。