MinGWexcutableをVisualC++によってコンパイルされたライブラリとリンクすることはどれほど安全ですか。
ここで説明されているようなもの。 http://www.codesynthesis.com/~boris/blog/2011/12/09/oci-mingw/
TL; DR「...OCIはCライブラリであるため、VC ++用の「公式」OCIインポートライブラリを取得oci.libし、名前を変更してlibclntsh.a、MinGW用のOCIを取得できます。」
これは起こるのを待っている事故ですか？何がうまくいかない可能性がありますか？
場合によります。
私の知る限り、Windows の同じプロセスで glibc と msvcrt が共存するのを止めるものは何もありません。単一の名前空間にマージされます)。
ただし、特定のライブラリには問題がある場合があります。たとえば、ライブラリが「関数はポインターを返し、free()完了時に解放する必要がある」と指定している場合、正しい解放、つまり、malloc()割り当てられたものに対応するもので解放する必要があります。同様に、関数が「パラメータはfree()関数によって解放されるバッファです」と述べている場合、対応するmalloc(). が使用される可能性がある場合にも、同様の問題が適用realloc()されます。
この問題は、MSVCRT20.dll と MSVCRT40.dll など、異なるバージョンの MSVCRT に対してコンパイルされた DLL を使用する場合にも発生します。
そのため、Windows ライブラリは常にメモリの割り当て方法を示しています。たとえば、CoTaskMemAlloc/CoTaskMemFree、LocalAlloc/LocalFree、HeapAlloc/HeapFree を参照してください。ドキュメントには、「必要なくなったら、バッファを CoTaskMemFree で解放する必要があります」と記載されている場合があります。または、独自の free/alloc ペアを提供することもできます。たとえば、「不要になったら、返されたバッファーを SuperLibraryFreeBuffer で解放する必要があります」(内部的には単に CRTfreeに委譲することができますが、少なくとも free の正しいバージョンになります)。
これは、windows が C 以外の言語でライブラリを記述できる多言語プラットフォームであるためです。今日、Lisp、Pascal などは C ランタイムの上のレイヤーであるという考えに慣れているかもしれません。ほとんどのプログラマーは、Pascal の場合のように真実ではない場合でも、おそらくそれを想定していますが、必ずしもそうではありませんでした。Pascal は、C が発明される前の 2 年間、DEC コンピューターで一般的に使用されていました。 DEC と多くの共通点があることを知っています。Windows の初期のバージョンはアセンブラーで大まかに書かれていました... Windows 3 のヘッダーに "パスカル" 呼び出し規則が使用されているのには理由があります...