問題タブ [implicit-conversion]

暗黙的な型キャストを実装しようとしているジェネリック クラスがあります。ほとんどの場合は機能しますが、インターフェースのキャストでは機能しません。さらに調査したところ、適用される「インターフェイスからのユーザー定義の変換」というコンパイラ エラーがあることがわかりました。場合によってはこれを強制する必要があることは理解していますが、私がやろうとしていることは正当なケースのように思えます。

次に例を示します。

それを使用するコード：

誰かが回避策を知っていますか、または私の場合は変換されておらず、Foo にのみ含まれているため、interfaceReferenceToBar暗黙的にキャストできない理由を満足のいく方法で説明できますか?Foo<IBar>

編集: 共分散が救いを提供するようです。C# 4.0 仕様で、共分散を使用したインターフェイス型の暗黙的なキャストが許可されることを期待しましょう。

クラスのコンストラクターに C++ キーワード 'explicit' を使用して、型の自動変換を防止できることは知っています。この同じコマンドを使用して、クラス メソッドのパラメーターの変換を防止できますか?

2 つのクラス メンバーがあり、1 つは bool をパラメーターとして取り、もう 1 つは unsigned int を受け取ります。int で関数を呼び出すと、コンパイラは param を bool に変換し、間違ったメソッドを呼び出しました。最終的に bool を置き換えることはわかっていますが、今のところ、この新しいルーチンが開発されているため、他のルーチンを壊したくありません。

c#で列挙型の暗黙的な変換を定義することは可能ですか?

これを達成できる何か？

そうでない場合、なぜですか？

ヒープ割り当てオブジェクトのラッパーとして機能するクラスを作成しているときに、この単純な例に要約できる暗黙的な型変換の問題に遭遇しました。

以下のコードでは、ラッパー クラスがヒープ割り当てオブジェクトを管理し、暗黙的にそのオブジェクトへの参照に変換します。これにより、暗黙的な変換が行われるため、ラッパー オブジェクトを引数として関数 write(...) に渡すことができます。

ただし、明示的なキャストが行われない限り、operator<<(...) の呼び出しを解決しようとすると、コンパイラは失敗します (MSVC8.0、Intel 9.1、および gcc 4.2.1 コンパイラで確認)。

では、(1) この場合、暗黙的な変換が失敗するのはなぜですか? （2）引数依存のルックアップに関連している可能性がありますか？（3）明示的なキャストなしでこれを機能させるためにできることはありますか？

最近の回答の1つで使用されているのを見ました：

ここで暗黙という言葉が必要なのはなぜですか? また、それはどういう意味ですか?

C ++では、戻り型に基づくメソッドのポリモーフィズムは許可されていません。ただし、暗黙の変換メンバー関数をオーバーロードする場合、これは可能と思われます。

誰かが理由を知っていますか？演算子は内部的にメソッドのように扱われると思いました。

編集：ここに例があります：

true == "true"JavaScript は比較とに対してどのように動作します(0 == "0")か?

コーディング標準シートで次のルールを見つけました。

条件で bool への暗黙的な変換に依存しないでください。

if (ptr) // 間違っている

if (ptr != NULL) // わかりました

この規則はどの程度合理的/有用ですか?

コンパイルされたコードのオーバーロードはどれくらいですか?

「//Compiles」の行がコンパイルされる理由と、「//DOS't Compile」の行がコンパイルされない理由を誰か教えてもらえますか?

A が暗黙的に B に変換可能であり、その逆ではない理由がわかりません。

ありがとう！