ForumKategorien

Diskussion zum Artikel "Verwendung von Objektzeigern in MQL5" - Seite 4

Neuer Kommentar
tol64:
Haben Sie eine Sicherheitslücke gefunden? )
Jep. Es ist ungöttlich, direkt so zu casten. In Plus gibt es dynamic_cast speziell für diesen Zweck, hier kann man nicht ganz korrekt casten und es ist eine potentielle Quelle für implizite und schwerwiegende Fehler. Und in Bezug auf die Ernsthaftigkeit ist es nicht viel besser als unsichere Zeiger und Referenzen.
denkir:

Wäre es nicht besser, Polymorphismus zu verwenden?

Ungefähr:

Die Sache ist die, dass die Erbenklassen CChartObjectRectLabel, CChartObjectButton und CChartObjectEdit ihre eigenen Methoden haben, auf die zugegriffen werden muss. Und die Basisklasse CChartObject aus der Standardbibliothek hat nicht die gleichen virtuellen Methoden.

Zu meinem obigen Beispiel...

Zugriff auf Methoden von Erbenklassen?


...dann sieht es so aus:

//--- objects[0]. // Wie erhält man Zugriff auf Methoden der Klasse CChartObjectEdit?
// 1.
   Print("((CChartObjectEdit *)objects[0]).BackColor(): ",((CChartObjectEdit *)objects[0]).BackColor());
//--- 2.
   CChartObjectEdit *e=(CChartObjectEdit *)objects[0];
   Print("e.BackColor(): ",e.BackColor());
   
//--- objects[1]. // Wie kann man auf Methoden der Klasse CChartObjectButton zugreifen?
// 1.
   Print("((CChartObjectButton *)objects[1]).State(): ",((CChartObjectButton *)objects[1]).State());
//--- 2.
   CChartObjectButton *b=(CChartObjectButton *)objects[1];
   Print("b.State(): ",b.State());
   
//--- objects[2]. // Wie erhält man Zugriff auf Methoden der Klasse CChartObjectRectLabel?
// 1.
   Print("((CChartObjectRectLabel *)objects[2]).BackColor(): ",((CChartObjectRectLabel *)objects[2]).BackColor());
//--- 2.
   CChartObjectRectLabel *r=(CChartObjectRectLabel *)objects[2];
   Print("r.BackColor(): ",r.BackColor());
TheXpert:
Das stimmt. Es ist unorthodox, direkt so zu casten. In Plus gibt es dynamic_cast speziell für diesen Zweck, hier kann man es nicht ganz korrekt casten und es ist eine potentielle Quelle für implizite und ernsthafte Fehler. Und im Ernst, es ist nicht viel besser als unsichere Zeiger und Referenzen.

Ja, bevor ich hier im Forum eine Frage gestellt habe, habe ich im Netz gefunden, dass C++ den dynamic_cast-Operator hat (ein Mechanismus der dynamischen Datenidentifikation).

Jetzt schaue ich mir den obigen Link an:

// Der Mechanismus der dynamischen Datentypidentifizierung ist nur für polymorphe Datentypen verfügbar. 
// Klassen (d. h. Klassen, die mindestens eine virtuelle Mitgliedsfunktion enthalten)

Es ist also eine obligatorische Bedingung? Und wenn es keine virtuellen Methoden in der Basisklasse gibt, dann wird dynamic_cast nicht funktionieren?

P.S. >>> Hier lese ich gerade mehr über dynamic_cast (MSDN).

TheXpert:
Scheiße, und danach reden Sie von Sprachsicherheit?

Wahrscheinlich denken Sie, dass Sie wie in C/C++ frei auf alles casten können.

Dem ist nicht so, und an der Sicherheit gibt es nichts auszusetzen.

Renat:

Wahrscheinlich denken Sie, dass Sie wie in C/C++ frei auf alles casten können.

Das ist nicht der Fall, und es gibt keine Sicherheitsprobleme.

Ich bin zufällig auf diesen Fehler gestoßen, der Ihre Worte zu bestätigen scheint. )

2014.11.06 14:33:36.588 OOP_Test (EURCHF,M5)   incorrect casting of pointers in 'Test1.mqh' (931,13)
Renat:

Das ist nicht der Fall, und es gibt nichts, was gegen die Sicherheit spricht.

Nein, Sie können normalerweise keine Überprüfung von dynamic_cast zur Kompilierzeit durchführen.
TheXpert:
Nein, es ist unmöglich, dynamic_cast zur Kompilierzeit zu prüfen.

Der obige Kommentar zeigt das Ergebnis der Casting-Prüfung in rantime.

Es ist sehr starr, es funktioniert auf RTTI-Mechanismus, weil wir genau wissen, wer wer im Falle von Geistern ist.

Renat:

Der obige Kommentar zeigt das Ergebnis der Casting-Prüfung in rantime.

Ups.... verwirrt. Ich dachte, es wäre ein Compiler. Dann nehme ich es zurück.
Das Tutorial hat mir das Verständnis von Polymorphismus erleichtert. Danke
12345
Neuer Kommentar