問題があります。次のようなクラス構造があります。

そこにいるそれらの衒学的な人々のためのいくつかのメモ：

• 私は読みやすくするためにこの例のクラスで public: を緩めています

• この例では、DerivesFrom が何か役に立つかどうかはすぐにはわかりません。ただし、私たちのアーキテクチャではそうであり、それが必要であることを信頼する必要があります。

• DLL_FLAG はマクロであり、コードのコンパイル時に

さて、問題：

LibraryA では、MyClass と MyCommonClass がエクスポートされます。MyCommonClass がエクスポートされるため、DerivesFrom もエクスポートされます (少なくとも VS2012 ではそう表示されます)。

次に、LibraryB が MyClass をエクスポートすると、DerivesFrom (wtf?) もエクスポートされます。

次に、(cmake によって定義されたビルド プロセスの一部として) MyExecutable.exe を LibraryA.dll および LibraryB.dll に対してリンクすると、重複した DerivesFrom (各ライブラリから 1 つ) があるため失敗します。

以前に見た、使用できないソリューション:

__declspec(dllexport) DerivesFrom を 1 つのライブラリで、インポートを別のライブラリで行います。ただし、これには、実際には存在しないはずのコードが多すぎます。次に、1 つのライブラリがクラスを「ホスト」するように強制しますが、その概念は私たちのシステムでは意味がありません。

「それをしないでください。」まあ、私は Visual Studio がそれをすべきではないと言います。または、DerivesFrom (および DerivesFrom のすべてのインスタンス化) が内部リンケージのみを持ち、そのシンボルがエクスポートされないように指定できる必要があります。

私は途方に暮れています：

• VS2012 がテンプレートを自動エクスポートし、各ライブラリが独自のものを使用することを拒否する理由。

• これらのテンプレートをエクスポートしないように指示できないのはなぜですか (DerivesFrom<> を持つクラスから 2 つのライブラリが派生する場合があるため、実行できない場合があります)。

• この問題を回避する方法。

Any ideas would be greatly appreciated!

「Interface_API」という関数をdllからエクスポートしようとしている次のコードがあります。

このコードをコンパイルすると、次の警告が表示され、関数がエクスポートされません。

以下のように宣言を変更すると、警告が表示されず、適切にエクスポートされます。

別のdllで使用したことがあり、正常に動作するため、少し混乱しています。どんな手掛かり？

__declspec プロパティを使用しようとしていますが、複数のインデックスを使用すると奇妙なエラーが発生します。Visual Studio で「式は完全なオブジェクト型へのポインターである必要があります」というエラーが表示されますが、コードは正常に実行されているようです。私が使用しているコードは次のとおりです。

この例では、多次元プロパティを使用するテンプレート クラスで __declspec プロパティを使用しています。括弧とパラメーターのセットを 1 つ削除すると、エラーがなくなり、コードが期待どおりに実行されるようです。コードが現在のように、Visual Studio でエラーがスローされ、引き続き実行されます。

なぜこれが懸念されるのですか？私はチームで働いており、エラーが発生した場合、他の人は満足せず、コードが機能しないと想定する可能性があります。このようなエラーを抑制する方法はありますか? なぜこうなった？

明確にするために: 以下の例が dll 依存性を示していることは承知しています。つまり、1 つのライブラリは自己完結型ではなく、機能するために別のライブラリに依存しています。

一般的な性質のさまざまな便利な関数を含むランタイム ライブラリ Utility.dll を作成しているとします。Utility.dll を使用する必要がある他のファイルに含まれるヘッダー ファイル Utility.h を作成します。ヘッダーファイルは次のようになります

ソース コード ファイル Utility.cpp をマシン コード (Utility.dll) にコンパイルするときに、BUILD_DLL が定義されていることを確認して、DLL_EXPORT が __declspec(dllexport) に置き換えられるようにします。これにより、関数が .dll ファイルにエクスポートされます。ヘッダー Utility.h をインクルードし、インポート ライブラリ (MS VS の場合は Utility.lib、g++ の場合は libUtility.a) とリンクし、BUILD_DLL を定義しないと、Utility.h の関数宣言は代わりに __declspec(dllimport) で始まり、関数が .dll からインポートされるコンパイラ (いわば)。

ここで、別のライブラリ MyLibrary.dll も構築しているとします。このライブラリは、Utility.dll の便利な関数の一部を使用したいと考えています。同様に、MyLibrary.h を次のように作成します。

MyLibrary.cpp を MyLibrary.dll にコンパイルすると、Utility.h がインクルードされ、Utility インポート ライブラリにもリンクされます。

これは私の質問につながります: MyLibrary.dll をコンパイルするときに BUILD_DLL も定義するので、これは Utility.h の関数宣言も読み取ることを意味します。

いいえ

MyLibrary.dll をコンパイルするときに、Utility.h の関数宣言を __declspec(dllimport)、MyLibrary.h の関数宣言を __declspec(dllexport) にしたくないですか?

私のプロジェクトは、メインの dll ライブラリにリンクする必要があるいくつかの静的ライブラリを介してビルドされ、結果として 1 つの dll が得られます。

属性を使用__declspec(dllexport)すると、スタティック ライブラリの指定された関数が dll に表示されなくなり、dll にリンクされていないライブラリがまったく表示されなくなります。

次に、エクスポートされた関数の適切な名前を取得するために各ライブラリを共有として構築し、それらに基づいて .def ファイルを作成しようとしました。.def ファイルを使用すると、結果が得られました。

1. __declspec(dllexport)私の場合、平等に.def-file行動すべきですか？

2. ソースから .def ファイルを生成することは可能ですか? 私は C++ コードを持っているので、API のマングリングとプレゼンス クラスのために自分で .def ファイルを書くことができません。一時的に生成された dll を使用した上記のアプローチは、本番環境では一貫性がありません。

アップデート

私のプロジェクトの構造について詳しく説明したいと思います。このソリューションは、いくつかのプロジェクト (モジュール) で構成されています。

各サブプロジェクトは、他のサブプロジェクトに弱く依存しています。明確にするために、それらが接続されていないと仮定しましょう。各モジュールには独自のパブリック インターフェイスがあります。すべてのモジュールを単一の動的ライブラリとして保持したいので、アーティファクトは ですdynamic_lib.dllが、実際には静的ライブラリはリンクされていません。

以下でこれを実行して、この機能にアクセスしたいと思います。Visual Studio では、「Part::read();」を実行することをお勧めします。その機能へのf12が機能します。

しかし、コンパイルすると、PartExport がクラス名であると見なされるため、構文エラーが発生します。この関数にアクセスしたり、MyClass のオブジェクトを作成するにはどうすればよいですか?

編集:クラスのすべての構文エラーは #include に起因することに気付きました。それが何を意味するのかわからない

dll ファイルに定義された多くのクラスを含むこの大規模なプロジェクトを取得しました。このプロジェクトの一部を抽出し、その部分から新しいプロジェクトを作成する必要があります。Visual Studio のコード マップを使用していくつかの dll ファイルを見つけることができましたが、いくつかのクラスがそこに表示されません。

どのdllファイルが何にリンクされているかを指定しているのは何ですか?

以下のコードを実行すると、ループの 2 回目の反復で OS 全体がハングします。タスク マネージャーを開くと、大量のメモリ リークが発生していることがわかります。コードの実行を開始した後、すべてのメモリが 4 秒でなくなりました。

コードは次のとおりです。

コード内のすべてをコメント アウトし、__declspec(align())宣言とのみをループdelete[]内に残すとfor、メモリ リークは依然として存在し、問題が実際にはこれら__declspecの s にあることが示されます。

関数とは次のようgenerate_random_1d_matrixになります。get_random_floatmain

ここで何がうまくいかないのか、そのメモリの問題を解決する方法を誰か教えてもらえますか?

アップデート

提供されたコードを変更しました。実際に問題が発生する部分だけを残しました。