アプリケーションでメモリを割り当て、dll/dylib から呼び出される関数で解放するのに問題はありますか?
しかし、dll/dylib から関数にメモリを割り当てて、呼び出し元アプリケーションで解放するには?
アプリケーションでメモリを割り当て、dll/dylib から呼び出される関数で解放するのに問題はありますか?
しかし、dll/dylib から関数にメモリを割り当てて、呼び出し元アプリケーションで解放するには?
静的ライブラリの場合、これは一般的に問題にはなりませんが、動的ライブラリの場合は通常、良い考えではありません。特にプロジェクト間で共有されるライブラリの場合。
問題は、呼び出し元のコードと動的ライブラリの間でメモリ割り当て関数 (new/delete、malloc/free) が正確に一致するようにする必要があることです。たとえば、C ランタイムを実行可能ファイルに静的にリンクしているが、動的ライブラリが動的にリンクされている (またはその逆) 場合、実行可能ファイルと動的ライブラリに対して malloc を実行する別のコードがあります。
問題を回避するために、動的ライブラリは一貫性を保証するために独自の alloc および free ルーチンを公開することがよくあります。
いいえ、機能するという意味で根本的な問題はありませんが、メモリ割り当てを行うアプリケーションは、削除 (または解放) を実行できるように、DLL に渡すことができるポインターを返す必要があります。
もちろん、他の人が指摘するように、アプリケーションと DLL の両方が同じメモリ割り当てを使用している必要があります。そうしないと、混乱が生じます。
ただし、危険であり、エラーが発生しやすくなります。一般に、メモリの割り当てと割り当て解除が同じ場所で処理され、割り当てられたオブジェクトにアクセスする必要がある他のものにポインタが渡された方がよいでしょう。
これは、メモリを割り当てて (大きな) 結果を返す DLL を呼び出す C# ライブラリで動作し、アプリケーションがそれらを終了したときに呼び出される delete メソッドを提供しました。うまくいきました。