class A { };
class B
{
A _a[];
public:
A * operator[](uint i) { return &_a[i]; }
const A * operator[](uint i) const { return &_a[i]; }
};
voidOnStart()
{
B b1;
const B b2;
b1[0]; // []
b2[0]; // [] const
}
class B
{
A _a[];
public:
A * operator[](int i) {...}
A * operator[](bool i) {...}
};
B b;
b[0]; // ok
b[true]; // ok
b[0 u]; // ambiguous call to overloaded function
この制約に長年耐えてきたのです。
これまでで初めての疑問が生まれました
これはある種の強権的な規制です。今の時代、その根拠は?また、文字束のクラスターを指定するのは、どのように便利なのでしょうか?十数種類のパラメーターを掛け合わせること?それは便利ですか?
その根拠は、テストエージェントとの 交換プロトコルにある。
文字の束を設定するには、その束をテキストファイルに書き出し、#property tester_fileを使って渡します。
しかし、1回のテストでは、テストエージェントにも 渡され、制限なく動作する。
静的な入力にも制限があるのはなぜですか?エージェントに一切渡さないことも可能です。
バグですらない場合は、改善要望として受け止めてください。
コンパイラのバグで、曖昧さエラーが発生します。最初のメソッドが最も適切な ものとして呼ばれるはずです。C++でテストしています。
ベストフィット法はどのように定義されるのですか?
その根拠は、テストエージェントとの 交換プロトコルにある。
文字の束を指定するには、その束をテキストファイルに書き出し、#property tester_fileを使って渡します。
エンドユーザー向け製品との相性は?以前は制限が正当化されていたかもしれませんが、他のデータ転送量から見て、そうではないでしょう。上限を上げても、相性が悪いという心配はありません。
どのように適していると判断しているのですか?
C++規格の話なら。
13.3 過負荷の解消オ ーバーロードの解決は、呼び出しの引数となる式のリストと、呼び出しのコンテキストに基づいて呼び出し可能な候補関数のセットが与えられたときに、呼び出すべき最適な関数を 選択するメカニズムである。最適な関数の選択基準は、引数の数、引数が候補関数のパラメータ型リストにどれだけ一致するか、(非静的メンバ関数の場合)オブジェクトが暗黙のオブジェクトパラメータにどれだけ一致するか、候補関数の他の特定の特性です。[注意:過負荷解消で選択された関数が文脈に合っていることを保証するものではありません。その他、関数のアクセス性などの制限により、呼び出し側のコンテキストでの使用が不正になる場合があります。
つまり、このように動作するはずです。
C++規格の話なら。
13.3 過負荷の解消オ ーバーロードの解決は、呼び出しの引数となる式のリストと、呼び出しのコンテキストに基づいて呼び出し可能な候補関数のセットが与えられたときに、呼び出すべき最適な関数を 選択するメカニズムである。最適な関数の選択基準は、引数の数、引数が候補関数のパラメータ型リストにどれだけ一致するか、(非静的メンバ関数の場合)オブジェクトが暗黙のオブジェクトパラメータにどれだけ一致するか、候補関数の他の特定の特性です。[注意:過負荷解消で選択された関数が文脈に合っていることを保証するものではありません。その他、関数のアクセス性などの制限により、呼び出し側のコンテキストでの使用が不正になる場合があります。
つまり、このように動作するはずです。
b2については、完全な曖昧さなし。b1がない。
適切なものはどのように決定されるのですか?
この例では、定数でないオブジェクトのメソッドが要求されているので、他のすべての条件が同じであれば、それを呼び出す必要があります。
キャスティングを削除して、両方のメソッドの引数をint型に すると、コードは正常にコンパイルされます。 つまり、MQLの問題はキャスティングについてです。 このキャスティングは、コードが同一であるため影響を及ぼしてはいけません。
b2については、完全に曖昧さがない。b1がない。
ここでは、曖昧さは必要ありません。単にオーバーロードされたメソッドが適用される順番であるべきです。つまり、オーバーロードを解決するための課題は、ジレンマを作り出すことではなく、最適な方法を選択することなのです。アクセス修飾 子はさておき、表から1番目のメソッドであるか、コンパイラの実装によるが、曖昧さはない。
しかし、例えば入力パラメータが異なる2つのメソッドがあったとします。
C++に戻ると、同じベクターが1つ持っています。
だから、これは至極当たり前のことなのです。
エンドユーザー向け製品との相性は?以前は制限が正当化されていたかもしれませんが、他のデータ転送量から見て、そうではないでしょう。上限を上げても、相性が悪いという心配はありません。
そもそも、最適化キャッシュでは、MT5、MT4ともに文字列パラメータは常に63文字に切り詰められています。
また、イベント送信時には、63文字以上の文字列を送信することはできません。
つまり、外から来るものは限られている
エンドユーザー向け製品については。ベンダーはその制約を考慮しなければならない。もし、それがわからないのであれば、販売する前に十分に製品をテストしていないことになる。