1

インターフェイス仕様「X」があるとしましょう。X は、との両方のタイプのメンバーの存在を保証XHeader.hする struct を呼び出すように呼び出します。ただし、実装定義のメンバーは禁止されているわけではなく、実際にそうすることで効率が向上する場合は推奨されます。私が働いている会社のために X の実装を作成する必要があり、いくつかの状態を保存するために私の実装に固有のいくつかのメンバーを持つことが非常に便利であることに気付いたので、私は次のように書きました:X_Fiddlefoobarint

typedef struct X_Fiddle {
    int foo; /* Guaranteed by spec */
    int bar; /* Guaranteed by spec */
    size_t dinky_dingbat; /* IMPLEMENTATION-SPECIFIC, DO NOT USE */
    unsigned char *dingbat_data; /* IMPLEMENTATION-SPECIFIC, DO NOT USE */
} X_Fiddle;

もちろん、これらは実装固有の詳細であり、将来のある時点で変更または消失する可能性があるため、使用すべきではない、dinky_dingbatまたは使用すべきではないことをユーザーに伝えることは何もありません。dingbat_data不透明なポインターのようなものを使用して実装を隠すことができない場合、そのような内部メンバーを目立たせるにはどうすればよいですか (またはそのようなものを隠すための他のトリック)? このような問題に対処するために一般的に使用される/標準的な方法はありますか? 私が考えることができる最善の方法は、先頭のアンダースコアのような命名規則を使用することですが、先頭のアンダースコアの規則がメンバー変数に適用されるかどうかはわかりません.C++固有の規則にも混乱していると感じています. また、それらに次のような名前を付けるかINTERNAL_dinky_dingbat、内部に含まれる内部型用に別の構造体を持つことも考えましたX_Fiddle、しかし、余分な入力を最小限に抑えたいので、やや嫌いです。または、実装固有の詳細がコメントとドキュメントに記載されている、上記のようなプレーンで通常の構造体を使用するだけで完全に受け入れられるのでしょうか。 ?

私がゼロから始めている、および/または私の会社/チームにこの特定のケースに関する慣習がないと仮定します。

4

2 に答える 2

2

PIMPL のイディオムが C++ のものであっても、実際には無名ポインターとしてプレーン C でより長く使用されてきましたvoid。

構造体に実装固有のプライベート フィールドを持たせる場合は、それらのプライベート フィールドの構造体を作成voidし、パブリック構造体にポインター フィールドを追加します。次に、このプライベート構造体を割り当てるinitor関数を用意し、パブリック構造体のポインター フィールドがそのプライベート構造体を指すようにします。createvoid

于 2013-06-05T12:25:30.543 に答える
1

GLib オブジェクト システムは、オブジェクト システムにデータの隠蔽と継承を提供します。アプリケーションで使用できない場合でも、少なくともいくつかのアイデアを得ることができます。

于 2013-06-05T12:33:41.840 に答える