Fragen zu OOP in MQL5 - Seite 80

 
Vladimir Simakov:

Ich stimme zu))) Das bin ich auf der positiven Seite).

Ich habe gesehen, wie sich das alles entwickelt, während ich geschrieben habe.

D.h. nicht auf der Plusseite, sondern auf der Schnauze der Vorgängerversion wird es funktionieren?

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:

Während ich dies schrieb, hat sich alles gewendet.

D.h. nicht auf der Plusseite, aber auf der Mündungsseite wird die vorherige Option funktionieren, oder?

Diese Option - ja))

Nur hat es zwei implizite dynamic_casts
 
Vladimir Simakov:

1) Hervorgehoben. Nur in der nächsten Zeile prüfen))) In dem Beispiel vom Ersteller der Lib, genau das Gegenteil, zuerst prüfen, dann werfen)
2) wenn JSONObject hat ein Erbe, warum sollte es fallen?

1) Im Grunde genommen wird ein und derselbe Code seit mehreren Tagen in diesem Thread diskutiert:hier, hier und hier.
Die Tatsache, dass Sie ein Problem in einem der Beispiele für die Nutzung der Bibliothek gefunden haben - gut gemacht, danke.
Sie haben jedoch ein Problem in der Logik der Verwendung der Bibliothek als Ganzes festgestellt, aber es stellt sich heraus, dass das Problem ein spezifisches Beispiel betrifft.

2) Wo haben Sie die Aussage gesehen, dass etwas nach unten gehen sollte?
Nein, es könnte viel schlimmer sein - der Code wird zwar funktionieren, aber falsche Ergebnisse liefern.

 
Sergey Dzyublik:

2) Wo haben Sie die Aussage gesehen, dass etwas nach unten gehen sollte?
Nein, es könnte viel schlimmer sein - der Code wird zwar funktionieren, aber falsche Ergebnisse liefern.

IMHO natürlich, aber wenn ich in lib, wenn ich auf ein Objekt durch einen Zeiger auf eine Basisklasse verweisen, undefiniertes Verhalten erhalten, sollte es in der Bibliothek Handbuch reflektiert werden (ist es da?), aber es sollte nicht sein)

 
Sergey Dzyublik:

Nein, es könnte viel schlimmer sein - der Code wird zwar funktionieren, aber falsche Ergebnisse liefern.

unwahrscheinlich, mein Beispiel ist eine Methode aus einer Basisklasse, JSONObject * ist das Ergebnis der Ausführung, es ist ein Zeiger auf den Parser, und die JSON-Parsing selbst in der abhängigen Methode geschieht mit dem empfangenen Zeiger, der in meinen zuvor erwähnten Fragen "genagelt" werden sollte

es gibt eine ganze Reihe von Prüfungen, im vorgeschlagenen Beispiel gibt es 3 Stück und in der abgeleiteten Klasse wird jeder Aufruf der Methoden getInt() und getDouble() mit Prüfungen verbunden

 
Vladimir Simakov:

IMHO natürlich, aber wenn ich in lib, wenn ich auf ein Objekt durch einen Zeiger auf eine Basisklasse verweise, undefiniertes Verhalten erhalte, sollte dies im Handbuch der Bibliothek reflektiert werden (gibt es das?), aber es sollte nicht so sein)

Noch einmal: Was haben Zeiger und Nicht-Zeiger, Handbücher usw. damit zu tun? ?
In Ihrem Beispiel wird ein Teil der LOGIK aus der Funktion entfernt, nämlich die Überprüfung vonjv.isObject()
Diese LOGIK wurde durch die Überprüfung mittels dynamic_cast ersetzt.
Für die aktuelle Version der Bibliothek ist alles in Ordnung, aber theoretisch, wenn in der nächsten Version wird es eine neue Klasse, dieJSONObject als Basis verwendet, nicht die Tatsache, dass Ihr Beispiel mit ihm richtig arbeiten können.

 
Sergey Dzyublik:

Noch einmal: Was haben Zeiger und Nicht-Zeiger, Handbücher usw. damit zu tun? ?
In Ihrem Beispiel wird ein Teil der LOGIK aus der Funktion entfernt, nämlich die Überprüfung vonjv.isObject()
Diese LOGIK wurde durch die Überprüfung mittels dynamic_cast ersetzt.
Für die aktuelle Version der Bibliothek ist alles in Ordnung, aber theoretisch, wenn in der nächsten Version wird es eine neue Klasse, dieJSONObject als Basis verwendet, nicht die Tatsache, dass Ihr Beispiel mit ihm richtig funktionieren wird.

Eine andere Version wird also auch nicht richtig damit arbeiten können)

 
Andrei Trukhanovich:
Es gibt keine UB, mql cast umfasst auch dynamic_cast. nur alles wird im Falle der falschen Zeiger fallen.

Ist es das? Im Falle von dynamic_cast wird nichts fallen, wenn Sie das Ergebnis auf NULL prüfen. Bei normalem Wurf fällt sie sofort ab. Oder habe ich es falsch verstanden?

 
Vladimir Simakov:

IMHO natürlich, aber wenn in lib, wenn ein Objekt durch Zeiger auf eine Basisklasse, ich undefiniertes Verhalten erhalten, dann sollte es im Handbuch der Bibliothek reflektiert werden (ist es dort?), aber es sollte nicht so sein)

Bei den Profis sollte es eine Ausnahme geben. Und ein Schreiben an die Autoren, denn eine Ausnahme ist keine gute Sache, sondern nur ein Vorwand. So etwas gibt es in mql nicht, daher werden die Klassen mit Blick auf die Zukunft und mit einem vollständigen Protokoll erstellt.

Was das besprochene json betrifft, so gibt es nur 2 Möglichkeiten, entweder man folgt dem Stil und den Lösungen des Autors oder man macht einen eigenen Fork. Der Rest ist böse. 😉

 
Vladimir Simakov:

Und das ist es wert))) Werfen Sie NIEMALS direkt von der Basis auf den Nachkommen - das ist UB (UNDEFINED BEHAVIOR).

Bei Pluszeichen ist es gefährlich, Verweise (ob aufwärts oder abwärts) über den Standard-Gimme-Operator zu setzen, der uns vertraut und bequem ist.

Grund der Beschwerde: