MQL5 コンパイラはクラスとそのポインタを区別しない - ページ 6 12345678910111213 新しいコメント Ilya Baranov 2019.01.11 14:38 #51 Alexey Navoykov:このポインタを暗黙のうちにオブジェクトにキャストする正しくは「暗黙のポインタ再参照」です。 のように、クラスメンバを 参照するときだけ暗黙のデリファレンスを残して、無効にする案を支持します。 m_a.foo() SemenTalonov 2019.01.11 17:02 #52 Alexey Navoykov:ここではその逆で、ポインタを 暗黙のうちにオブジェクトにキャスト(デリファレンス)し、それにoperator=を適用しています。 fxsaberも昨日言及しています。 論理的にはMQLのルールと矛盾しませんが(operator=を呼び出すことは他のどのオブジェクト・メソッドも呼び出すことと同じだからです)、このようなコードを理解する上で曖昧になり、見つけにくいエラーにつながります。また、これはoperator=だけでなく、少なくとも==と!=にも関係します。 C++では、+-<>[]という演算子を適用することができるので、おそらく他の演算子についてもこのようなキャスティングを禁止すべきなのでしょう。 つまり、C++でポインタに対して許可されている演算子をポインタに適用する場合、このポインタをオブジェクトに暗黙的にキャストすることは禁止されています。 これに対応して、上記の例ではコンパイルエラーが 発生することになります。はい、そうですか。このような簡単な例を使って、ポインタとオブジェクトは別のものであり、混同してはいけないということを、疑いを持つすべての人に示したかったのです。 そして、このような状況下では、少なくとも、間違って、コンパイルしてテストに合格しても、実際の条件下では失敗するようなコードを作らないように、また、販売用に書かれたものならなおさら悪いように、コードを書く一定のスタイルが必要になるのです。すべてが「暗黙の了解」になっているコードの中で、エラー箇所を見つけるのは簡単なことではないでしょう。 Alexey Navoykov 2019.01.11 17:43 #53 SemenTalonov:すべてが「暗黙の了解」になっているコードの中からエラーの場所を見つけ出すのは、かなり大変なことでしょう。 うん、ちょっと暗黙の了解がありすぎるかな? Ilya Malev 2019.01.12 13:20 #54 開発者はこのままでよいのでは?今また、言語を変え始めて、多くのプログラムがコンパイルできなくなったり、最悪の場合、期待通りに動かなくなったりしたら、世界中が大騒ぎになることでしょう。私の考えでは、μlのオートオブジェクトは初歩的なもので、機能を限定したアンダーポインタ(自動削除機能付き定数ポインタ)であり、ほとんどは全く使う必要がない(ガベージコレクタを除く)ものだと思います。 SemenTalonov 2019.01.12 14:02 #55 Ilya Malev:開発者はこのままでよいのでは?今また、言語を変え始めて、多くのプログラムがコンパイルできなくなったり、最悪の場合、期待通りに動かなくなったりしたら、世界中が大騒ぎになる。ここでの変更は最小限です。にコンパイルルールを追加するだけです。 #property strict 現在では良品とされているガラクタをコンパイルできないようにするためです。 Ilya Malev 2019.01.12 15:31 #56 SemenTalonov:今、良しとされている異端を編纂させないようにね。like A a a = new A?あるいは、具体的にどのようなものなのか)は、今や誰もが使っているので、全く効果はない。しかし、A a, *b = a; と書くとランタイムエラーが発生します。この場合、コンパイラは他のすべての型と同様に「初期化されていない変数 'b' の使用可能性が高い」という警告を明示的に発生させなければなりません。全くコンパイルエラー でない場合。しかし、代入そのものが原因ではなく、初期化されていない変数にオーバーロードされた関数を使用したために、当然ながらランタイムエラーが発生するのです。これは本当にバグで、コードの過剰な最適化に関係しているようです。また、一般的にオートをディノに、その逆をディノに割り当てることは異端ではなく、これらは有用な機能かもしれません。 しかし、私はオブジェクトの暗黙的なコピーというものを完全に取りやめてしまうつもりです。C++では標準的なものですが。実はこれが悩みの種なんです。 SemenTalonov 2019.01.12 16:49 #57 Ilya Malev:like A a a = new A?あるいは、具体的にどのようなものなのか )まあ、それは言うまでもないことですが。ここにメモリリークがあります。 イリヤ・マレフしかし、一般的には、オートとディノ、その逆を割り当てることは異端ではなく、これらは便利な機能かもしれません。 そう、そのままでいい。しかし、明示的。そして、それは私のミスではなく、私がやらなければならないことなのです。 Alexey Navoykov 2019.01.12 16:54 #58 SemenTalonov:まあ、当たり前のことなんですけどね。ここにメモリリークがあります。まあ、このリークは純粋にあなたのせいです。 左にオブジェクトがあるのなら、なぜそんな構成を書いたのでしょう? しかし、逆にポインタに何かを代入して、それが突然デリファレンスされるような状況は、明らかなエラーとなる。 ここではフライもカツもすべてがごっちゃになっている。話題のディスカッションについてです。 SemenTalonov 2019.01.12 16:55 #59 Alexey Navoykov:左側にオブジェクトがある場合、なぜそのような構造を書くのでしょうか?ヒューマンファクター!コンパイラはそれを最小限に抑える必要があります。 Alexey Navoykov 2019.01.12 17:01 #60 SemenTalonov:ヒューマンファクター!コンパイラはそれを最小限に抑える必要があります。 つまり、ポインタの暗黙的な再参照を全面的に禁止しろということですか? それを喜ぶ人がここにたくさんいるとは思えませんね。 12345678910111213 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
このポインタを暗黙のうちにオブジェクトにキャストする
正しくは「暗黙のポインタ再参照」です。
のように、クラスメンバを 参照するときだけ暗黙のデリファレンスを残して、無効にする案を支持します。
ここではその逆で、ポインタを 暗黙のうちにオブジェクトにキャスト(デリファレンス)し、それにoperator=を適用しています。 fxsaberも昨日言及しています。
論理的にはMQLのルールと矛盾しませんが(operator=を呼び出すことは他のどのオブジェクト・メソッドも呼び出すことと同じだからです)、このようなコードを理解する上で曖昧になり、見つけにくいエラーにつながります。また、これはoperator=だけでなく、少なくとも==と!=にも関係します。 C++では、+-<>[]という演算子を適用することができるので、おそらく他の演算子についてもこのようなキャスティングを禁止すべきなのでしょう。
つまり、C++でポインタに対して許可されている演算子をポインタに適用する場合、このポインタをオブジェクトに暗黙的にキャストすることは禁止されています。 これに対応して、上記の例ではコンパイルエラーが 発生することになります。
はい、そうですか。このような簡単な例を使って、ポインタとオブジェクトは別のものであり、混同してはいけないということを、疑いを持つすべての人に示したかったのです。
そして、このような状況下では、少なくとも、間違って、コンパイルしてテストに合格しても、実際の条件下では失敗するようなコードを作らないように、また、販売用に書かれたものならなおさら悪いように、コードを書く一定のスタイルが必要になるのです。すべてが「暗黙の了解」になっているコードの中で、エラー箇所を見つけるのは簡単なことではないでしょう。
すべてが「暗黙の了解」になっているコードの中からエラーの場所を見つけ出すのは、かなり大変なことでしょう。
開発者はこのままでよいのでは?今また、言語を変え始めて、多くのプログラムがコンパイルできなくなったり、最悪の場合、期待通りに動かなくなったりしたら、世界中が大騒ぎになることでしょう。
私の考えでは、μlのオートオブジェクトは初歩的なもので、機能を限定したアンダーポインタ(自動削除機能付き定数ポインタ)であり、ほとんどは全く使う必要がない(ガベージコレクタを除く)ものだと思います。
開発者はこのままでよいのでは?今また、言語を変え始めて、多くのプログラムがコンパイルできなくなったり、最悪の場合、期待通りに動かなくなったりしたら、世界中が大騒ぎになる。
ここでの変更は最小限です。にコンパイルルールを追加するだけです。
現在では良品とされているガラクタをコンパイルできないようにするためです。
今、良しとされている異端を編纂させないようにね。
like A a a = new A?あるいは、具体的にどのようなものなのか)は、今や誰もが使っているので、全く効果はない。
しかし、A a, *b = a; と書くとランタイムエラーが発生します。この場合、コンパイラは他のすべての型と同様に「初期化されていない変数 'b' の使用可能性が高い」という警告を明示的に発生させなければなりません。全くコンパイルエラー でない場合。しかし、代入そのものが原因ではなく、初期化されていない変数にオーバーロードされた関数を使用したために、当然ながらランタイムエラーが発生するのです。これは本当にバグで、コードの過剰な最適化に関係しているようです。
また、一般的にオートをディノに、その逆をディノに割り当てることは異端ではなく、これらは有用な機能かもしれません。
しかし、私はオブジェクトの暗黙的なコピーというものを完全に取りやめてしまうつもりです。C++では標準的なものですが。実はこれが悩みの種なんです。like A a a = new A?あるいは、具体的にどのようなものなのか )
まあ、それは言うまでもないことですが。ここにメモリリークがあります。
しかし、一般的には、オートとディノ、その逆を割り当てることは異端ではなく、これらは便利な機能かもしれません。
そう、そのままでいい。しかし、明示的。そして、それは私のミスではなく、私がやらなければならないことなのです。
まあ、当たり前のことなんですけどね。ここにメモリリークがあります。
まあ、このリークは純粋にあなたのせいです。 左にオブジェクトがあるのなら、なぜそんな構成を書いたのでしょう?
しかし、逆にポインタに何かを代入して、それが突然デリファレンスされるような状況は、明らかなエラーとなる。
ここではフライもカツもすべてがごっちゃになっている。話題のディスカッションについてです。
左側にオブジェクトがある場合、なぜそのような構造を書くのでしょうか?
ヒューマンファクター!コンパイラはそれを最小限に抑える必要があります。
ヒューマンファクター!コンパイラはそれを最小限に抑える必要があります。