問題タブ [ambiguous-call]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
518 参照

c# - 戻り型が明示的である場合に異なる型を返すメソッド間であいまいな呼び出し

重複の可能性:
C#でのあいまいな呼び出しに関する質問

私には次の2つの方法があります。

次の呼び出しでは、「メソッド間のあいまいさ」エラーが発生します。

オブジェクトが経由またはその他TypeAではなく明示的に戻るように要求している場合、これはどのように発生しますか?var


TypeATypeBは別々のクラスであり、共通点はありません。

0 投票する
1 に答える
234 参照

scala - 継承された内部クラス scala を使用したオーバーロードされた定義へのあいまいな参照

したがって、問題のあるコードは次のとおりです。

コンパイラは、dynamicsと の両方で、署名Worldに一致すると言います。GridWorldただし、 inWorldは抽象的であり、 で実装されGridWorldているため、 を呼び出していることは明らかなように思えますGridWorld.this.dynamics

私が気付いたもう 1 つのことは、 in を削除するextends super.StateSimpleGridWorld、すべてが正常に機能することです (理由がわかりませんGridWorld.State。ここで定義されている機能が必要です)。説明はありますか?ありがとう!

更新Stateとにかく、 inが継承しSimpleGridWorldない場合、ルートトレイトで定義された未実装のものを参照するため 、デザインパターンが非常に奇妙に見えます( in の実装は に存在しない可能性のある機能を使用する可能性があるため、これは理にかなっています)。しかし、私が欲しいのは:GridWorld.this.StatedynamicsWorldGridWorldGridWorld.this.StateSimpleGridWorld.this.State

  1. XXXWorld.this.Stateそれを継承する必要がありますsuper.State(または単に使用する必要があります)
  2. dynamicssuper.dynamicsここでオーバーライドされない限り、スーパー トレイト/クラスで実装されている場合は常に を参照します。

これどうやってするの?それはまったく無関係な質問ではないと思います。おそらく、前の質問への答えは、パターンを再設計する方法を教えてくれるでしょう.

0 投票する
5 に答える
2662 参照

c# - Enumerable と MoreLINQ の間のあいまいな ZIP 呼び出しを解決するにはどうすればよいですか?

拡張メソッドの解決で問題が発生しました。LINQ と MoreLINQ にはメソッドが含まれており、 4.0バージョンzipから .NET に存在し、常にMoreLINQライブラリにありました。しかし、古き良き拡張メソッド構文で実装の 1 つを使用することはできません。したがって、このコードはコンパイルされません

エラー:

この投稿でJon Skeetによって作成されたMoreLINQのConcatメソッドの適切な解決策を見つけましたが、メソッドの適切な解決策については知りません。stringzip

注:いつでも静的メソッド呼び出し構文を使用でき、すべて正常に動作します

しかし、拡張構文シュガーのポイントを少し見逃しています。LINQ および MoreLINQ 呼び出しを使用したデータ変換が多数ある場合は、途中で静的メソッド呼び出しを使用したくありません。

このあいまいさを解決するためのより良い方法はありますか?

0 投票する
1 に答える
394 参照

java - Java 7 で実行されている Eclipse Indigo は、メソッドへのあいまいな参照を表示しません。

Java 1.5 で実行されていたアプリケーションがあります。それはコンパイルされ、うまく実行されました。最近、Java 1.7 に移行することにしました。

コードを Maven でコンパイルすると (pom.xml で Java バージョンを更新しました)、いくつかのコンパイル エラーが表示され、いくつかのメソッドへの参照があいまいであることがわかりますが、これは事実です。ただし、Eclipse では、これらのエラーは表示されません (Eclipse のコンパイラーも 1.7 に更新しました)。

私の友人が Eclipse Juno で同じことをしようとしたところ、エラーが表示されました。

それを修正する方法はありますか?

ありがとう

0 投票する
2 に答える
5375 参照

c++ - ISO C++ によると、これらはあいまいです。

コンソールへの書き込みとバイナリファイルへの書き込みの両方で、シフト演算子「 << 」をオーバーロードする必要があります..

fstreamのオーバーロードに問題がありますが、ostreamのオーバーロードには問題ありません。次のとおりです。

私のヘッダーで:

私のcppファイルで:

私が直面しているエラーは次のとおりです。

関数 `std::fstream& operator<<(std::fstream&, const Fotografia&)':

これまでに理解したのは、作成したばかりのオーバーロードされた関数と標準の fstream << の間にあいまいさがあるということです。char * を書き込もうとしている間、オーバーロードされた関数はクラス「Fotografia」(私が作成したもの) に対してのみ機能するはずなので、今、私が理解していないのはその理由です。

「::」スコープで fstream 演算子を呼び出すことでこの問題を解決できると思いましたが、よくわかりません。

誰かここで私を助けてくれませんか? :)

編集:

ヘッダーのコードとコンストラクターのコードを投稿しています

これはcppにあります:

0 投票する
1 に答える
187 参照

c# - c# ではなく vb であいまいな呼び出しが行われるのはなぜですか?

私はC#で次のメソッドを持つクラスを持っていました:

新しいオプションのパラメーターを追加する必要がありました。下位互換性を維持するために、それぞれ 1 つのパラメーターを持ついくつかのメソッドを追加し、以前のメソッドを書き直して新しいメソッドを呼び出しました。

これは c# で機能するようですが、null だけで MyMethod を呼び出すとあいまいになることは承知しています (最後のリストの最初の 2 つのメソッドのいずれかである可能性があります)。

ただし、Visual Basic から MyMethod を呼び出そうとすると、IntelliSense にリストされません。手動で書くと、「あいまいな呼び出し」というエラーが発生しました。

なぜこれが起こるのですか?

0 投票する
2 に答える
746 参照

c++ - 明らかにあいまいな呼び出しは、GCC でコンパイル エラーを引き起こしません。

GCC が次のプログラムの呼び出しをあいまいと見なさないという事実に驚きました。foo()

上記の関数呼び出しはtrue、GCC 4.7.2 および GCC 4.8.0 (ベータ版) ではコンパイルされて返されますが、Clang 3.2 および ICC 13.0.1ではコンパイルされません(予想どおり)。

これは「診断不要」のケースですか、それとも GCC のバグですか? C++11 標準への参照が推奨されます。

0 投票する
2 に答える
270 参照

c++ - 引数に依存するルックアップのあいまいさを回避する目立たない方法

これが私のケースです:

Foo::atype を持ち、 a も指定するライブラリを使用しようとしてFoo::swapいます。私が使用している別のライブラリにはstd::vector<Foo::a>インスタンス化があります。Visual Studio 11.0 を使用して Windows でこれをコンパイルしようとしていますが、修飾されていないスワップ呼び出しを行うstd::vector::swapマップがダウンしていることに気付きました。_Swap_adl

これが、ADL とあいまいな関数の解決に関する問題に私を陥れるものです。Foo::swap私が消費しているライブラリに「大きな」変更を加えることなく(std::swapFooなどからスワップを削除/名前変更するだけのもの)、使用できるようにする魔法はありますか?

編集:何が起こっているのかとエラーをキャプチャする最小限の例を追加します。

コードの効率性についてはコメントしませんが、@ http://pastebin.com/Ztea46aCのエラー ログを参照すると、内部で何が起こっているかがわかります。これはコンパイラ固有の問題ですか、それともこのコードから得られるより深い学習はありますか?

編集2:問題の特定のタイプに特化しようとしましたが、あいまいさは解決しません。これがなぜそうであるかについての指針も同様に役立ちます。

http://pastebin.com/sMGDZQBZは、この試行のエラー ログです。

0 投票する
2 に答える
735 参照

ambiguity - JavaCC のあいまいさ: 「より長い一致」のリストから特定の一致を選択するようにパーサーに指示するにはどうすればよいですか?

一部の入力に対して、パーサーは「より長い一致の可能性のある種類: { <式>, <テキスト> }」を提示しますが、何らかの奇妙な理由で間違ったものを選択します。

これはソースです:



この文法を使用して"a.bc.d"を解析しようとすると、 " FOUND A <EXPRESSION> MATCH (a.bc.d) " となります。

私の質問は、入力を <TEXT> ではなく <EXPRESSION>として解析することを選択したのはなぜですか?

また、パーサーに正しいパスを選択させるにはどうすればよいですか? 私は無数の LOOKAHEAD シナリオを試しましたが、成功しませんでした。

正しいパスは、たとえば"a.bc.d"を入力として使用する 場合は<TEXT>であり、 "{a.bc.d}"の場合は<EXPRESSION>です。

前もって感謝します。

0 投票する
1 に答える
192 参照

c++ - これらのオーバーロードがあいまいではないのはなぜですか?

次のコードは、gcc と clang で正常にコンパイルされます。

オーバーロードの解決が最初のオーバーロード ( identity<T>::type1 つ) を選択しているようです。

誰かがオーバーロードがあいまいではない理由を説明できますか? 私が知る限り、それらの唯一の違いは、最初の引数は非推定コンテキストであり、2 番目の引数はそうではないということですが、テンプレート引数を明示的に提供しているので、私はしません。なぜそれが重要なのかわかりません。