MQL5におけるOOPに関する質問 - ページ 80

 
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);
}
 
Igor Makanu:

と書いている間に、すっかり逆転してしまいました。

つまり、プラス側ではなく、マズル側で、前のオプションが機能するのでしょうか?

このオプションは - はい))

ただ、2つの暗黙のdynamic_castがあります。
 
Vladimir Simakov:

1) ハイライト次の行だけチェックする))libの作成者の例では、ちょうど逆で、まずチェック、次にキャスト)
2)JSONObjectが 継承者を持つ場合、なぜドロップする必要があるのか?

1) このスレッドでは、基本的に同じコードが数日間にわたって議論されています。
ユーザーのライブラリの利用例のひとつに問題を発見してくれたこと、よくやった、感謝します。
しかし、ライブラリ全体の使い方のロジックに問題があるとのことでしたが、実は特定の例に関する問題であることが判明しました。

2)何かが下がるはずだという発言は、どこで見ましたか?
いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。

 
Sergey Dzyublik:

2)何かが下がるはずだという発言は、どこで見ましたか?
いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。

もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映されるべきですが(あるのかな?)、そうではないはずです)

 
Sergey Dzyublik:

いいえ、もっと悪いこともあり得ます。コードは正常に動作しますが、誤った結果をもたらします。

私の例は基底クラスのメソッドで、JSONObject * は実行結果であり、パーサーへのポインターです。そして、子孫メソッドでの json 解析そのものは、受け取ったポインターで行われます。

提案した例では3個のPCがあり、派生クラスでは getInt()、getDouble()メソッドの呼び出しごとにチェックが発生するため、非常に多くのチェックが必要です。

 
Vladimir Simakov:

もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出た場合、ライブラリのマニュアルに反映されるはずですが(あるのでしょうか)、そういうことはないはずです)

繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか??
この例では、関数からロジックの一部が削除されます。すなわち、チェックjv.isObject()
このロジックは dynamic_cast によるチェックに置き換えられています。
現在のライブラリのバージョンではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれを正しく動作させることができるという事実ではなく、そのクラスがあります。

 
Sergey Dzyublik:

繰り返しになりますが、ポインターと非ポインター、マニュアルなどはどう関係するのでしょうか??
この例では、ロジックの一部が関数から削除されています。すなわち、jv.isObject()
このロジックは dynamic_cast によるチェックに置き換えられています。
現在のバージョンのライブラリではすべてOKですが、理論的には、次のバージョンでJSONObjectを ベースとして使用する新しいクラスがある場合、あなたの例がそれで正しく動作するという事実ではありません。

だから、別のバージョンも正しく動作させることはできない)

 
Andrei Trukhanovich:
UBはありません。mqlのキャストはdynamic_castも含んで います。

そうなんですか?dynamic_castの場合、結果がNULLであるかどうかをチェックしても何も落ちません。通常のキャストでは、すぐに落ちます。それとも私が勘違いしていたのでしょうか?

 
Vladimir Simakov:

もちろんIMHOですが、libで、基底クラスへのポインタでオブジェクトを参照したときに、未定義の挙動が出るのであれば、ライブラリのマニュアルに反映させるべきですが(あるのでしょうか)、そんなことはないはずです)

プロでは例外があるはずです。作者への手紙も、例外は良いことではなく、ただの差し金ですから。mqlにはそれがないので、クラスは完全なプロトコルで将来を見据えたものを作り上げています。

jsonについてですが、作者のスタイルと解決策に従うか、自分でフォークを作るかの2択しかありません。 あとは邪道です。😉

 
Vladimir Simakov:

そして、その価値は十分にあります)))ベースからディセンダントへ直接キャストすることは絶対にしないでください。

プラスでは、私たちにとって身近で便利な標準のキャスト演算子で参照をキャストするのは(上向きでも下向きでも)危険である。

理由: