タイピングに関する質問 - ページ 3

新しいコメント
 
Ilya Malev:

テンプレートのミスマッチエラーは、おそらくコンパイル時に発生するはずです。


しかし、配列オブジェクトが存在する状況下で

最初のケースでは、Array[int] の呼び出しが演算 = の左パラメータとして使用されており、double型の 変数ではないため、このようなエラーは発生しないはずですが、2番目のケースでは、右パラメータであり、左パラメータはdouble 型の 変数です。

型オーバーロードは禁止されており、C++標準にも明示的に書かれています（C++と同様のものとしてµlも-おそらく）。

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

その理由は上記の通りです。だから、あなたの演算子[]は無効なのです。

 
pavlick_:

型によるオーバーロードは禁止されており、C++の標準にも明示的に書かれています。

上にあげた確率的な理由。だから、演算子[]は無効です。

基準についてではなく、常識に基づいたロジックについて回答したのです。あなたの「相当の」理由の定義は、私の議論を否定するものではありません。型付け操作のオーバーロードの 可能性（暗黙的なものも含む）は、コンテキストから特定の明示的に定義された型にキャストするオーバーロード操作なので、引用した規格と矛盾するものではありません。

あまり明確でなかったかもしれませんが、この明確化により、より明確になることを期待しています。


追伸：もちろん、私の架空のコードは標準と矛盾しています。しかし、解読する必要があるなら（より正確な質問の言い回しを自分で考えていたので）、次のようになるはずです。

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
演算子type()を標榜するのであれば、構わない。プラスからのインデントを提唱するのであれば、ある特定の問題（おそらくもっと別の方法で美しく解決できるはず-なぜか最初の投稿のようにねじれたことはない）を解決するために（戻り値型によるオーバーロードを許す）それに反対するのです。
 
pavlick_:
演算子type()を標榜するのであれば、構わない。プラスからのインデントを提唱するのであれば、ある特定の問題（きっともっと別の方法で美しく解決できるはず-なぜか最初の投稿のようなねじれ方はしなかった）を解決するために、私は（戻り値型によるオーバーロードを許可する）それに反対します。

そうですね、結局、タイピングオペレーターの導入は大賛成です。なぜなら、私が最初の投稿で述べた問題を、より「慣習的」（規格に適合し、おそらく一般的にはより正しい）な方法で解決してくれるからです。

 
Ilya Malev:

追伸：もちろん、私の作ったコードは規格に反しています。

なぜ規格に反するかというと、プラスで完全に成立しているからです。そして、mclにはドックが全くない。
 
pavlick_:
なぜ矛盾しているかというと、プラスではかなり有効なのです。そして、mqlにはドックが一切ないのです。

なぜなら、もともと戻り値の型が異なる2つの同じ operator[] 関数が存在したからです（第2版で修正しました）。これは規格で禁止されています。しかし、型を（暗黙的に含む）引用することは禁じられているわけではなく、まだ実装する時間がないだけなのだそうです。mql5の素晴らしい開発速度を考慮すると、遅かれ早かれ実装されると思います。特に、私以外の人がフォーラムで注目してくれたら...。

 
Ilya Malev:

戻り値の型が異なる2つの同じ operator[] 関数があったため。これは規格で禁止されています。暗黙のうちにも）タイプすることが禁じられているわけではなく、まだ実装する時間がないだけなのだそうです。mql5の開発スピードの速さを考えると、遅かれ早かれ実装されるのではと思います。特に、私以外の人が掲示板で注目してくれれば...。

最後のコードは......いいんですけどね。

 
pavlick_:

最後のコードは......いいんです。

大丈夫ですが、まだmql5では動きません。mql5のイノベーションに期待し、追いかけましょう。このように、ユーザー型を通常の配列と同じように扱えないために、配列オブジェクトを適切に実装できないことが、個人的にはずっと気になっていた。自作すると、内蔵の配列のような使い勝手の良さはなく、最初から欠陥品になってしまうのです。

 
Ilya Malev:

大丈夫ですが、まだmql5では動きません。mql5のイノベーションに期待し、追いかけましょう。このように、ユーザー型を通常の配列と同じように扱えないために、配列オブジェクトを適切に実装できないことが、個人的にはずっと気になっていた。アレイを自作すると、最初は内蔵のアレイと使い勝手が変わらないという欠陥がある。

まあ、大きな奇跡は期待できないし、言語ももうあまり開発されてないので、ゴーストオペレーターが追加されることもないだろうけど。ここで私は、そのようにできないことに具体的なストレスを感じています。

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

が、言っても無駄だと思う。

 
pavlick_:

まあ、大きな奇跡は期待できないし、もう言語が発展していないのだから、ゴーストオペレーターを追加することもないだろう。特に気になるのは、そのやり方ができないことです。

でも、話しても無駄だと思うんです。

何が問題なのか、よくわからない。オブジェクトの初期化は、Init()のような別のメソッド、もしかしたら仮想メソッドで実装できないのでしょうか？

12345678910
新しいコメント