問題タブ [msvcrt]

デフォルトで CRT バージョン 9 を使用する COM dll の開発に VS2008 を使用していますが、新しい CRT と互換性のない TSF (テキスト サービス フレームワーク) を使用しています。解決策は互換性のあるものを使用することだと思いますが、CRTのバージョンを指定するにはどうすればよいですか?

Visual Studio には、必要な C ランタイム ライブラリの種類を選択できるコンパイル フラグ /MD および /MT があります。

実装の違いは理解できましたが、どちらを使用すればよいかまだわかりません。長所/短所は何ですか?

私が聞いた /MD の利点の 1 つは、これにより誰かがランタイムを更新できることであり (おそらくセキュリティ問題にパッチを当てるなど)、私のアプリはこの更新の恩恵を受けるでしょう。私には、これはほとんど非機能のように思えます: 新しいバージョンに対してテストすることを許可せずに、人々が私のランタイムを変更することを望んでいません!

私が興味を持っているいくつかのこと：

• これはビルド時間にどのように影響しますか? (おそらく /MT は少し遅いですか?)
• 他の意味は何ですか？
• 多くの人が使っているのはどれ？

WaitForSingleObject()またはで作成したハンドルを呼び出すとどうなりますCreateFile()か_get_osfhandle()?

説明する価値のない理由で、 でWaitForSingleObject()作成した HANDLE を待機するために使用したいと思います。これは可能ですか？_get_osfhandle(fd)fd_open()

実際に試してみたところ、一部のマシンでは期待どおりに動作し (HANDLE からより多くのデータを読み取ることができるため、HANDLE は常にシグナル状態になっています)、一部のマシンでWaitForSingleObject()は許可すると無期限にブロックされます。

MSDN のページにWaitForSingleObject()よると、サポートされているのは、「変更通知、コンソール入力、イベント、メモリ リソース通知、ミューテックス、プロセス、セマフォ、スレッド、および待機可能なタイマー」のみです。

さらに、 CRT ファイル記述子のCreateFile()代わりに使用した場合は異なりますか?_get_osfhandle()

Visual StudioプロジェクトでCランタイムライブラリに静的にリンクするか動的にリンクするかについて、両側で議論を読みましたが、何を考えればよいのかまだ完全にはわかりません。

私のプロジェクトは、いくつかのサードパーティライブラリ（Python、HDF5、Trilinos、およびMicrosoft MPI）を取り込みます。これらのライブラリはそれぞれ、最終的な実行可能ファイルと同じランタイムライブラリでビルドする必要があります（そうでない場合、それらをリンクすることはできません）。静的にリンクする場合、これらの各ライブラリにはCランタイムのコピーが含まれます。最終的な実行可能ファイルにはランタイムの複数のコピーが含まれ、それらのいずれも相互に対話できないため、これにより問題が発生する可能性があることを読みました。しかし、同じシンボルが複数定義されている場合、リンカーは文句を言いませんか？

「DLLHell」は避けたいのですが、ランタイムの複数のコピーを静的にリンクすることで発生する可能性のある潜行性のエラーが心配です。私は物事を間違って読んでいますか？

また、Visual Studio 2005を使用していますが、ServicePack1ランタイムには下位互換性がないことを読みました。これは、SP1なしでビルドされたアプリは、同じ名前（msvcr80.dllなど）であっても、SP1 dllを持つマシンでは実行されないことを意味しますか？

現在のユーザーのディスク クォータを超えようとして失敗したことを示す EDQUOT エラーの発生を検出する C++ コードを UNIX から Windows に移植しています。Windows にディスク クォータ機能があることはわかっていますが、Visual Studio の <errno.h> には EDQUOT がありません。Visual Studio の <errno.h>にはENOSPC があります。これは、UNIX が EDQUOT として表現するものを CRT が表現する方法である可能性があります。この理論を肯定または否定できる人はいますか? そして、これがこれを処理する方法ではない場合、何ですか?

複数のDLLとQTを使用するC++プログラムには、Windowsのmallocが原因であることが確認できるパフォーマンスの問題のために、mallocの置換（ tcmallocなど）を装備する必要があります。Linuxの場合は問題ありませんが、Windowsの場合はいくつかのアプローチがあり、どれも魅力的ではありません。

1.新しいmallocをlibに入れ、最初にリンクするようにします（その他のSO-質問）

これには欠点があります。たとえば、strdupは古いmallocを引き続き使用し、freeはプログラムをクラッシュさせる可能性があります。

2. lib.exe（Chrome）を使用して静的libcrtライブラリからmallocを削除します

これはクロム/クロムについてテスト/使用（？）されていますが、crtの静的リンクでのみ機能するという欠点があります。静的リンクには、1つのシステムライブラリがmsvcrtに対して動的にリンクされている場合に問題があり、ヒープの割り当て/割り当て解除に不一致がある可能性があります。私が正しく理解していれば、tcmallocは動的にリンクされ、すべての自己コンパイルされたdllに共通のヒープが存在する可能性があります（これは良いことです）。

3.パッチcrt-ソースコード（firefox）

Firefoxのjemallocは、明らかにWindows CRTソースコードにパッチを適用し、新しいcrtを構築します。これにも、上記の静的/動的リンクの問題があります。

これを使用して動的MSVCRTを生成することも考えられますが、ライセンスでは同じ名前のパッチが適用されたMSVCRTを提供することが禁止されているため、これは不可能だと思います。

4.実行時にロードされたCRTに動的にパッチを適用します

一部の商用メモリアロケータは、そのような魔法を実行できます。tcmallocでも可能ですが、これはかなり醜いようです。いくつかの問題がありましたが、修正されました。現在、tcmallocでは、64ビットウィンドウでは機能しません。

より良いアプローチはありますか？コメントはありますか？

ASSERTE マクロを使用して事前条件を確認しています。その定義によると、ASSERT_BASE を使用しており、_CrtDbgReportW を呼び出してメッセージを出力します。_CrtDbgReportW の出力先はどこですか?

アプリケーションがデバッガーから起動された場合、デバッガー ウィンドウに移動すると思います。デバッガーの下にない場合、メッセージはどこに行きますか?

以前の質問と同じように見えますが、この近いシナリオを観察してください。それでも私は答えを得ていません。したがって、重複として報告しないでください。

10 個の依存関係を持つプロジェクトがあります。最初に、メイン プロジェクトの C/C++ コード生成セクションで /MTD オプションを使用してコンパイルし、そのすべての依存関係が正常にビルドされました。

次に、オプションを /MTD から /MDd に変更すると、すべての依存プロジェクトが正常にビルドされます。ただし、メイン プロジェクトでは、次のエラーが報告されます。

どうすればこれを修正できますか?

次の形式のリンカー エラーが発生し続けます。

libcmtd.dll msvmrtd.dllいくつかの要素 (例: _mkdir )は既に定義されています...

そして、それらを解決する方法がわかりません。

完全なエラー メッセージは次のとおりです。

プライベート: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) はすでに LIBCMTD.lib(typinfo.obj) で定義されています

MSVCRTD.lib(ti_inst.obj): エラー LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) は LIBCMTD.lib で既に定義されています(typinfo.obj)

この問題の解決を手伝ってもらえますか?