問題タブ [opaque-pointers]

ライブラリは、不透明なデータ型を定義します。

また、クライアント コードは を取得して解放する必要がありOpaqueStruct*ます。ライブラリ ソースにアクセスできます。

残念ながら、そのポインターを保存することshared_ptrもunique_ptrできず、 エラーが発生します: 'sizeof' から incomplete type への無効なアプリケーションです。

私が考えることができる最善の方法は、この投稿からfinally ガード を借りることです。

不透明な構造体ポインタに RAII を使用するにはどうすればよいですか?

この質問は、MISRAC:2012 ガイドラインに従った ISO C99 でのコーディングに関するものです。

Dir 4.8「If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden」と Dir 4.12「動的メモリ割り当てを使用してはならない」に関するガイダンスを探しています。

C で抽象データ型を実装する場合、ADT の内部状態を記述する構造体へのポインタであるハンドルを使用して ADT を参照するのが一般的です。これは、Dir 4.8 に従って不透明なポインターを使用して行うことができ、内部の詳細がユーザーから隠されているという利点があります。

通常、これらの ADT は複数存在する可能性があるため、複数のハンドルを作成する方法が必要です。これは、初期化関数でハンドルによって参照される内部詳細にメモリを割り当てることで解決できますが、これは Dir 4.12 では許可されていません。

もう 1 つのオプションは、初期化ルーチンがユーザーによって提供された静的に割り当てられたハンドルへのポインターを受け取ることですが、これは不透明なポインターを使用して行うことはできません。

以下に問題を示します。

この問題は、この質問 Static allocation of opaque data typesでも​​説明されていますが、MISRAC:2012 ガイドラインに関しては説明されていません。

説明されている 1 つの解決策は、クライアント コードで使用できるハンドルの静的に割り当てられたプールを使用することです。このソリューションは技術的に準拠しているようです。ただし、ここでは動的メモリ割り当ての概念がまだ存在しているようです。ハンドルは静的に割り当てられますが、ソフトウェアが正しく機能するのに十分なハンドルが使用可能かどうかは、コンパイル中にコンパイラーによって判断できないと私は主張します。

この問題に対する私の解決策は、Dir 4.8 に関する逸脱を記述し、不透明でないポインターと、ADT の内部の詳細を変更してはならないことをユーザーに明確にする強力な命名規則を使用することです。

Dir 4.8 および Dir 4.12 を満たし、他の MISRAC:2012 ルールに違反しない、この問題を解決するための広く受け入れられている方法があるかどうかに興味があります。どんなコメントでも大歓迎です。

私はサードパーティのモジュール ラッパーに取り組んでいます。メインのヘッダー ファイルにサードパーティ関連のヘッダー ファイルが含まれていないことを願っています。すべてのパラメーターの型と戻り値の型は、宣言するだけで不透明です。しかし、次のように定義された無名構造があります。

サードパーティのヘッダー ファイルを変更できません。私はそれを宣言する考えはありません。ここに私が試したことと私が得たエラーメッセージがあります

1.

2.

このような匿名構造体を宣言するにはどうすればよいですか?

データ型の不変条件のエンコードに多くの時間を費やしましたが、現在、FFI を介してライブラリを C に公開する作業を行っています。言語の壁を越えてデータ構造をマーシャリングするのではなく、不透明なポインターを使用して C が AST を構築できるようにし、evalHaskell では文字列を C にマーシャリングするだけで済みます。

これは、よりわかりやすくするためのコードです。

ただし、私が知る限り、これは型の安全性を無視しているようです。基本的に、C が Haskell に渡すものは何でも、そのタイプであると想定され、Haskell で dsl を書いた理由を完全に否定します。StablePtr を使用してタイプ セーフを維持する利点を得る方法はありますか? 私が最後に望んでいるのは、C で不変式を再実装することです。

ノードが

私のデータ構造には、戻り値の型を持つ多くの関数がありstruct node *、ユーザーにこの型を不透明として扱いたいと思っています。リンクされたリストの例では、そのような関数はたとえばget_next(struct node<T> *n)またはinsert_after(struct node<T> *x, struct node<T> *y). 非常に少数の関数、つまりnodes を割り当てたり、フィールドを取得/設定したりする関数だけdataが、 について何かを知る必要がありTます。

「無視」して、ユーザーが気にする必要のない関数Tのようなものとのみ対話できるようにする、より良い方法はありますか? C から来る私の直感的な反応は、 との間でキャストすることですが、それはあまりエレガントに聞こえません。typedef struct node * opaque_handleTvoid*

編集: CygnusX1 のコメントは、私があまりにも多くの保証を回避しようとしていると同時に、型システムにあまりにも多くの保証を求めていることを確信させました。キャスティングと間接化を犠牲にして、 Tbe let back に戻ります。void *

ハッシュマップ データ構造の反復子インターフェイスを設計しています。現在のデザインは次のようになります。

ただし、これには反復子オブジェクトのヒープ割り当てが必要であり、クライアントは完了時に反復子を解放することを忘れないでください。スタックのイテレータをmap_iterator_new返すと、コードは次のようになります。

ただし、これには、map_iterator構造体の定義をクライアント コードに提供する必要があります (そうしないと、不完全型エラーが発生します)。この定義を非表示にして、宣言のみを提供したいと思います。

これを達成する方法はありますか？基本的に、クライアント コードに「この構造体は X バイトを使用するため、スタックに割り当てることができますが、そのメンバーにアクセスする方法は教えていません」と伝える方法を探しています。

編集：標準Cのみでお願いします！(コンパイラ拡張/プラットフォーム固有の機能はありません)

C言語で簡単なインターフェースパターンを実現しようと考えています。

重要な特徴は、インターフェイスのパブリック ヘッダーによって提供される不透明な構造体に複数の定義を提供することです。つまり、実装が異なれば、その構造体に異なる基盤となるデータが提供されます (したがって、異なる翻訳単位間では、同じ構造体が異なる実装を持つことになります)。

これが良いデザインパターンなのか悪いデ​​ザインパターンなのか、参考になるものは見つかりませんでした。少なくとも、C標準で保証されている共通の最初の要素の一貫した順序とパディングにのみ依存しており、厳密なエイリアシングルールに違反していないようです(私が見る限り)。もちろん、C でオブジェクト指向のパターンがあることは知っていますが、この特定のパターンが使用されていることはわかりませんでした。

これは受け入れられますか？そのようなパターンも使用されましたか？(何も見つかりませんでした)

理解を容易にするために、以下に 3 つのソース ファイルの実際の例を示します。

reader.h (パブリック インターフェイスの定義)

reader.c (インターフェイスのグルー ロジック)

reader1.h (インターフェース、ヘッダーの実装)

reader1.c (インターフェースの実装、コード)

main.c (使用例)

おそらく、インターフェイスは実装者に別のヘッダー ファイルを提供し、関数ポインターを含む構造体 head の定義を提供する必要があります。多くのメソッドを持つクラスのオブジェクト サイズを最小化するために、それらを含むクラス構造を指すことさえあるかもしれません。

したがって、基本的には、以前のバージョンの Swift を使用しているこのStackOverflow の回答から上記のコードを見つけました。Swift 3.0 では、上記の初期化子AudioConverterRefは使用できません。

AudioConverterRefはオーディオ コンバーター オブジェクトへの参照であることに気付きましたAVAudioConverter。

では、短い質問は、上記のコードを Swift 3.0 でどのように記述すればよいでしょうか? AudioConverterRefそして、より長い質問は、を参照するだけの を作成する用途は何AVAudioConverterですか? すべての変数はオブジェクトへの参照だけではありませんか?