問題タブ [c++-cli]

C ++ / CLIIDisposableは、refクラスにデストラクタを実装するときに、スキャフォールディングを生成するのに役立ちます。また、デストラクタを実装していないが、クラスにを実装するメンバー変数があるIDisposable場合IDisposableは、クラスに再び自動的に実装されます。IDisposableこれは非常に便利で、C＃での処理方法よりもはるかに優れています。

msclr::com::ptr（RCWを含むスマートポインター）を保持するrefクラスを実装するときに、この動作に遭遇しました。

私の特定のケースでは、クラスによって参照されるCOMオブジェクトは、一部のアンマネージリソースを「ロック」せず、CLRが認識できないアンマネージメモリを事実上消費します。したがって、クラスを実装しないことで、refクラスのユーザーを混乱させないようにしたいと思いますIDisposable。代わりに、GC APIを使用して適切なメモリプレッシャーを追加することにより、CLRにCOMオブジェクトの存在を認識させたいと思います。

したがって、問題は次のとおりです。IDisposableデストラクタを実装していないが、IDisposableメンバー変数を保持しているrefクラスでの実装を抑制する方法はありますか？

注意：これは、クラスのユーザーが基になるCOMオブジェクトを決定論的に破棄できないため、間違ったことになることがよくありますが、特定の状況を考えると、公開するIDisposableと、refクラスのユーザーを混乱させる可能性があります。問題のrefクラスを破棄する必要はありません。

1つのオプションは、デストラクタなしでmsclr :: com::ptrのバリアントを実装することだと思います。

IDisposableの自動追加を抑制する他の方法をいただければ幸いです。ありがとう。

答え

_aComObjectmsclr :: com :: ptr（）へのハンドルとして宣言しmsclr::com::ptr<IWhatever>^ます。その場合、コンパイラはTestcom ptrオブジェクトの「所有者」であるとは見なさず、Testが削除されたときにそれを破棄しません。

私は Visual Studio 2008 SP1、2 つの C++/CLI プロジェクト、proj1 と proj2 を持っています。proj2 は proj1 に依存していますが、奇妙な方法です (以下を参照)。プロジェクトの依存関係で、proj2 が proj1 に依存することを指定します。また、proj2 参照には proj1 が含まれます。次に、proj1 を proj2 のフレンドにしたいので、「フレンド アセンブリ」の MSDN ページにあるように、proj2 のどこかに次のコードを記述します。

コンパイルすると、proj1.dll が既に参照されているため、proj2 プロジェクト設定からプロジェクト参照を削除する必要があることがわかります (したがって、/FU フラグを削除します)。

バグ (?) が発生します: proj2 から proj1 の参照を削除しても、ソリューションの Project Dependencies で proj2 が proj1 に依存することを指定すると、VS2008 ですべて正常にコンパイルされます。しかし、MSBUILD はプロジェクト参照を解析し、proj2 用の新しい一時プロジェクトを作成し、ADDS /FU:proj1.dll を作成し、BUILD は失敗します。

質問 1: この MSBuild の動作を無効にする方法はありますか?

次に、プロジェクトの依存関係で依存関係を削除すると、MSBuild は正常にビルドされますが、Visual Studio は proj1 と proj2 を並行してコンパイルしようとして失敗します。これは、proj2 がはるかに小さく、最初にコンパイルされるためです...ビルドと実行は役に立ちますが、すべての開発者マシンで実行する必要があります。この設定をソリューションに保存することはできません。ビルドが遅くなるなど...

質問 2:「プロジェクトの依存関係」を条件付きオプションにする方法はありますか? 私はVS2008とMSBuildのためにそれをしたい...

いくつかの型定義を含む小さな名前空間があり、これを使用してコードをよりきれいに見せます。ただし、これらのタイプのいずれかを使用するすべてのファイルに「using namespace ...」行を追加する必要はありません。ファイルに #include を追加する必要があるからです。

MyFile.cpp:

typedefs.h:

名前空間宣言の直後に「using namespace」行を追加してもよろしいですか? そうでない場合、なぜですか？

私はカスタムイベントをC++/ CLIで書いています（私はほとんどadd / removeメソッドだけを気にしています）：

すべてがうまく機能しますが、C＃でIntellisenseを見ると、見苦しいパブリックraise_Xyzメソッドが表示されます。

イベントを非公開にせずにそれを隠す方法について何かアイデアはありますか？

どんな助けでも大歓迎です。

編集：

パブリックraise_Xyzメソッドを別の可視性修飾子（私の場合は内部）でマークすることにより、それらを排除することができました。これは、クラスの外部からイベントを発生させることができないことを意味します。それは私にとっては大丈夫です。しかし、私は単純なイベントでさえ気づきました

raise_XXXメソッドを生成し、それらは保護されます。それを防ぐ方法はありますか？

インターフェイスとして単一のクラス (COM ではなく...単純な C++ クラス) をエクスポートするだけのアンマネージ C++ DLL があります。このクラスを C# で使用したいのですが、単に C# にインポートすることはできないと言われました。

私の C# アプリケーションでこのクラスを使用する正しい方法は何ですか?

多数の C++ 静的ライブラリに依存する C++/CLI ラッパー DLL を作成しています。一部の関数呼び出しでは、アンマネージ ポインターが渡されることを想定しています。適切に渡すにはどうすればよいですか?

また、他の関数は、「this ポインター」が void* として渡されることを想定しています。「これ」を渡す正しい方法は何ですか?

これが私のクラス定義です...

問題のポインタが使用されている私の使用法は次のとおりです...

&mClient と "this" を使用すると、次のコンパイラ エラーが発生します... 1>.\VBLoadSimulatorDll.cpp(40): エラー C2664: 'CIsmaClient::Create': パラメーター 1 を 'cli::interior_ptr' から ' に変換できませんCIsmaClient **' 1> with 1> [ 1> Type=CIsmaClient * 1> ]

1>.\VBLoadSimulatorDll.cpp(40): エラー C2664: 'CIsmaClient::Create': パラメーター 5 を 'VBLoadSimulator::RTPClient ^const' から 'VOID *' に変換できません

この質問がすでに回答されている場合は申し訳ありませんが、見つけることができませんでした。

C++ プログラムの関数が呼び出されたときに C# フォームを開こうとしています (メイン プログラムは C++-cli にあり、フォームは C# にあります。動作を試すためだけに空のフォームです)。私は Visual Studio 2005 を使用しており、ソリューションに両方のプロジェクトがあります。C# プロジェクトは単なるフォームであり、クラス ライブラリとして構成しました。ただし、C++ プログラムの関数に移動するときは、最初に次のように入力します。

私は C++ の経験がほとんどなく、さまざまな組み合わせを試しましたが、うまくいきませんでした。C++ プロジェクトが CLI と互換性を持つようになりました。必要なものはすでに含まれています：

いくつかの大きな間違いがあることは承知していますが、このフォームを実行するだけで十分です。どうもありがとうございました。

編集：すでに参照を追加しました。

これは、継承されたすべてのメソッドが再実装されていることを確認するために内部のすべてのクラスをテストできるように、C++/CLI およびマネージド C++ アセンブリを見つける方法として始まりました。これをビルド プロセスのステップとして追加し、二度と起こらないようにしたいと思います。

この問題について考えると、使用されている .NET 言語を特定できると興味深いので、少し興味がわきました。このため、もう少し踏み込んで、すべての .NET 言語のアセンブリを比較しました。これまでのところ、リフレクションを介して .NET アセンブリの任意のセットからの型と属性データを比較する、私が作成した小さなプログラムを通じて見つけたものは次のとおりです。

• C# - AssemblyConfigurationAttribute あり、GuidAttribute あり
• VB - 多くの追加の「My」タイプ (例: MyApplication、MySettings) があり、GuidAttibute があります
• F# - 使用されるコンパイラのバージョンも指定する FSharpInterfaceDataVersionAttribute があります。
• C++ (/clr:safe を除くすべて) - 追加の型が多数あります (FrameInfo、type_info)
• C++ /clr:safe - 固有のリフレクション機能がないようです。

次の順序で解析するのが合理的かもしれません。

1. FSharpInterfaceDataVersionAttribute があれば F# です
2. 私が見つけた余分な型の膨大なセットに含まれている場合、それは C++ です。
3. 「My*」タイプがあれば VB です。
4. AssemblyConfigurationAttribute または GuidAttribute がある場合は C# です。
5. C++ /clr:Safe である可能性が高い

ただし、これは恐ろしいハッキングであるため、ここでチェックインして、利用可能な別のオプションがないことを確認したいと思いました.

前回の質問で、C++-cli プログラムで C# フォームを実行することについて尋ねました。動作するようになりましたが、問題が発生しています。私は簡潔にしようとします。

私の C++ プログラムは、C# フォームを実行し、その中でいくつかの単純な関数を実行する必要があります (カウンターを増やして表示する)。ただし、これを行う最善の方法はわかりません。init 関数で初期化されたフォームがあります。

C++-cli

...

C++ プログラムの他の一部の関数は、単に incCounter を呼び出します。私の問題は、別の関数から incCounter への 2 回目の呼び出しで C# Form1 が null (this == null) になるため、incCounter の関数コードを使用できますが、クラス変数は使用できません。プログラムが FormProject を破棄したかのように、奇妙です。

C#

私は何を間違っていますか？問題がUIにある場合に備えて、実際にフォームを無効にし、関数と変数を使用しています（呼び出しなど）。Form1 をクリアする C++ init 関数 (コードの最初のチャンク) を終了していますか?

C++-CLI プロジェクトで C# クラスを使用しようとしていますが、Visual Studio では、C# オブジェクトへのハンドル (^) を関数内のローカル スコープでしか宣言できません。私がそれを機能させる唯一の方法は、ハンドルへのグローバルポインターを宣言することでした：

しかし、関数内にオブジェクトを作成し、そのアドレスをグローバル ポインターに渡すと、次のようになります。

関数が終了し、他の C++-CLI 関数内で incCounter 関数を使用しようとすると、オブジェクトがなくなったように見えます (デバッガーは this == null と表示します)。C++-CLI で C# コードのグローバル ハンドルを持つ方法はありますか? 何らかの理由でグローバルハンドルが禁止されていると思いますが、私にはアイデアがありません。これを行う必要があります。ありがとうございました。

編集：

null 参照例外を発生させます。なんで？