MQL5におけるOOPに関する質問 - ページ 80 1...737475767778798081828384858687...96 新しいコメント Igor Makanu 2020.06.11 17:19 #791 Vladimir Simakov:そうですね)))それはプラス側の私です)) 書いているうちに、その展開が見えてきました。 プラス側ではなく、旧バージョンの銃口の上に置くとうまくいくのでは? JSONObject * CActor::getJSONObject(const string json)const { JSONParser parser; JSONValue *jv = parser.parse(json); if (jv != NULL && jv.isObject() && (EACTOR_TYPE)(((JSONObject *)jv).getInt("ActorType")) == ActorType) return(jv); Print(__FUNCTION__ + "parser error, json = ",json); delete jv; return(NULL); } Vladimir Simakov 2020.06.11 17:23 #792 Igor Makanu:と書いている間に、すっかり逆転してしまいました。つまり、プラス側ではなく、マズル側で、前のオプションが機能するのでしょうか?このオプションは - はい)) ただ、2つの暗黙のdynamic_castがあります。 Sergey Dzyublik 2020.06.11 17:30 #793 Vladimir Simakov: 1) ハイライト次の行だけチェックする))libの作成者の例では、ちょうど逆で、まずチェック、次にキャスト) 2)JSONObjectが 継承者を持つ場合、なぜドロップする必要があるのか? 1) このスレッドでは、基本的に同じコードが数日間にわたって議論されています。 ユーザーのライブラリの利用例のひとつに問題を発見してくれたこと、よくやった、感謝します。 しかし、ライブラリ全体の使い方のロジックに問題があるとのことでしたが、実は特定の例に関する問題であることが判明しました。 2)何かが下がるはずだという発言は、どこで見ましたか? いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。 Vladimir Simakov 2020.06.11 17:45 #794 Sergey Dzyublik:2)何かが下がるはずだという発言は、どこで見ましたか? いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。 もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映されるべきですが(あるのかな?)、そうではないはずです) Igor Makanu 2020.06.11 18:03 #795 Sergey Dzyublik:いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。 私の例は基底クラスのメソッドで、JSONObject * は実行結果であり、パーサーへのポインターです。そして、子孫メソッドでの json 解析そのものは、受け取ったポインターで行われます。 提案した例では3個のPCがあり、派生クラスでは getInt()、getDouble()メソッドの呼び出しごとにチェックが発生するため、非常に多くのチェックが必要です。 Sergey Dzyublik 2020.06.11 18:09 #796 Vladimir Simakov:もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出た場合、ライブラリのマニュアルに反映されるはずですが(あるのでしょうか)、そういうことはないはずです) 繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか?? この例では、関数からロジックの一部が削除されます。すなわち、チェックjv.isObject() このロジックは dynamic_cast によるチェックに置き換えられています。 現在のライブラリのバージョンではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれを正しく動作させることができるという事実ではなく、そのクラスがあります。 Vladimir Simakov 2020.06.11 18:11 #797 Sergey Dzyublik:繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか?? この例では、ロジックの一部が関数から削除されています。すなわち、jv.isObject() このロジックは dynamic_cast によるチェックに置き換えられています。 現在のバージョンのライブラリではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれで正しく動作するという事実ではありません。 だから、別のバージョンも正しく動作させることはできない) Aleksey Mavrin 2020.06.11 20:13 #798 Andrei Trukhanovich: UBはありません。mqlのキャストはdynamic_castも含んで います。 そうなんですか?dynamic_castの場合、結果がNULLであるかどうかをチェックしても何も落ちません。通常のキャストでは、すぐに落ちます。それとも私が勘違いしていたのでしょうか? Maxim Kuznetsov 2020.06.11 20:46 #799 Vladimir Simakov:もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映させるべきですが(あるのでしょうか)、そんなことはないはずです) プロでは例外があるはずです。作者への手紙も、例外は良いことではなく、ただの差し金ですから。mqlにはそれがないので、クラスは完全なプロトコルで将来を見据えたものを作り上げています。jsonについてですが、作者のスタイルと解決策に従うか、自分でフォークを作るかの2択しかありません。 あとは邪道です。😉 Alexey Navoykov 2020.06.12 06:58 #800 Vladimir Simakov:そして、その価値は十分にあります)))ベースからディセンダントへ直接キャストすることは絶対にしないでください。 プラスでは、私たちにとって身近で便利な標準のキャスト演算子で参照をキャストするのは(上向きでも下向きでも)危険である。 1...737475767778798081828384858687...96 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
そうですね)))それはプラス側の私です))
書いているうちに、その展開が見えてきました。
プラス側ではなく、旧バージョンの銃口の上に置くとうまくいくのでは?
と書いている間に、すっかり逆転してしまいました。
つまり、プラス側ではなく、マズル側で、前のオプションが機能するのでしょうか?
このオプションは - はい))
ただ、2つの暗黙のdynamic_castがあります。1) ハイライト次の行だけチェックする))libの作成者の例では、ちょうど逆で、まずチェック、次にキャスト)
2)JSONObjectが 継承者を持つ場合、なぜドロップする必要があるのか?
1) このスレッドでは、基本的に同じコードが数日間にわたって議論されています。
ユーザーのライブラリの利用例のひとつに問題を発見してくれたこと、よくやった、感謝します。
しかし、ライブラリ全体の使い方のロジックに問題があるとのことでしたが、実は特定の例に関する問題であることが判明しました。
2)何かが下がるはずだという発言は、どこで見ましたか?
いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。
2)何かが下がるはずだという発言は、どこで見ましたか?
いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。
もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映されるべきですが(あるのかな?)、そうではないはずです)
いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。
私の例は基底クラスのメソッドで、JSONObject * は実行結果であり、パーサーへのポインターです。そして、子孫メソッドでの json 解析そのものは、受け取ったポインターで行われます。
提案した例では3個のPCがあり、派生クラスでは getInt()、getDouble()メソッドの呼び出しごとにチェックが発生するため、非常に多くのチェックが必要です。
もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出た場合、ライブラリのマニュアルに反映されるはずですが(あるのでしょうか)、そういうことはないはずです)
繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか??
この例では、関数からロジックの一部が削除されます。すなわち、チェックjv.isObject()
このロジックは dynamic_cast によるチェックに置き換えられています。
現在のライブラリのバージョンではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれを正しく動作させることができるという事実ではなく、そのクラスがあります。
繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか??
この例では、ロジックの一部が関数から削除されています。すなわち、jv.isObject()
このロジックは dynamic_cast によるチェックに置き換えられています。
現在のバージョンのライブラリではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれで正しく動作するという事実ではありません。
だから、別のバージョンも正しく動作させることはできない)
UBはありません。mqlのキャストはdynamic_castも含んで います。
そうなんですか?dynamic_castの場合、結果がNULLであるかどうかをチェックしても何も落ちません。通常のキャストでは、すぐに落ちます。それとも私が勘違いしていたのでしょうか?
もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映させるべきですが(あるのでしょうか)、そんなことはないはずです)
そして、その価値は十分にあります)))ベースからディセンダントへ直接キャストすることは絶対にしないでください。
プラスでは、私たちにとって身近で便利な標準のキャスト演算子で参照をキャストするのは(上向きでも下向きでも)危険である。