Der Quellcode im Text sollte mit den beigefügten Dateien in Einklang gebracht werden, insbesondere im Listing GetCriticalError_Unsafe.mq5 wird auf die nicht existierende Variable status statt auf pstatus (wie in der Datei) verwiesen.
Und welchen Sinn macht es, in jeder der CShape-Erbenklassen einen eigenen Variablentyp zu definieren?
Auch hierzu würde ich gerne eine Erklärung hören. Beim Wechsel vom Beispiel GetCriticalError_OnDemand zu GetCriticalError_Unsafe reduzierte sich die gesamte Änderung praktisch darauf, den Typ des Funktionsarguments von CHello *pobject auf CHello &pobject zu ändern. Gleichzeitig blieb der Funktionsaufruf unverändert - ein Zeiger (CHello *) wurde dort übergeben. In diesem Fall, so der Autor,"bekommen wir wieder einen kritischen Fehler. Der Punkt ist, dass, wenn ein Objekt per Referenz übergeben wird, der kritische Fehler in der Phase des Funktionsaufrufs auftritt, in der ein nicht initialisiertes Objekt übergeben wird". In diesem Fall handelt es sich jedoch um einen Zeiger und nicht um eine Referenz, die an die Funktion übergeben wird. Es stellt sich die Frage, woher das kommt. Könnten Sie bitte die von MQL5 verwendeten Regeln für die implizite Umwandlung von Zeigern in Referenzen und zurück erläutern? Oder verweisen Sie auf die Stelle in der Dokumentation, an der dies beschrieben wird. Wenn der Compiler die strenge Typisierung unterstützt, würde das Beispiel einfach nicht kompiliert werden, weil eine Funktion mit einem Argument des erforderlichen Typs fehlt.
Der Quellcode im Text sollte mit den beigefügten Dateien in Einklang gebracht werden, insbesondere im Listing GetCriticalError_Unsafe.mq5 wird auf eine nicht existierende Variable status anstelle von pstatus (wie in der Datei) verwiesen.
Danke, im Artikel und in der Datei korrigiert.
Welchen Sinn hat es, in jeder der CShape-Nachfolgeklassen eine eigene Typvariable zu definieren?
Ich würde auch gerne einige Klarstellungen zu diesem Thema hören. Beim Wechsel vom Beispiel GetCriticalError_OnDemand zu GetCriticalError_Unsafe reduzierte sich die gesamte Änderung praktisch auf die Änderung des Typs des Funktionsarguments von CHello *pobject zu CHello &pobject. Gleichzeitig blieb der Funktionsaufruf unverändert - ein Zeiger (CHello *) wurde dort übergeben. In diesem Fall, so der Autor,"bekommen wir wieder einen kritischen Fehler. Der Punkt ist, dass, wenn ein Objekt per Referenz übergeben wird, der kritische Fehler in der Phase des Funktionsaufrufs auftritt, in der ein nicht initialisiertes Objekt übergeben wird". In diesem Fall handelt es sich jedoch um einen Zeiger und nicht um eine Referenz, die an die Funktion übergeben wird. Es stellt sich die Frage, woher das kommt. Könnten Sie bitte die von MQL5 verwendeten Regeln für die implizite Umwandlung von Zeigern in Referenzen und zurück erläutern? Oder verweisen Sie auf die Stelle in der Dokumentation, an der dies beschrieben wird. Wenn der Compiler strikte Typisierung unterstützen würde, würde das Beispiel einfach nicht kompiliert werden, weil es keine Funktion mit einem Argument des erforderlichen Typs gibt.
Im Prinzip wird dieses Mitglied nirgendwo verwendet, Sie können es entfernen. Theoretisch kann es in Nachkommen verwendet werden, um Funktionen zu implementieren, die vom Objekttyp abhängen.
Wenn eine Funktion, die einen Parameter als Zeiger akzeptiert, explizit definiert ist, wird sie verwendet. Gibt es keine solche Funktion, wird der Zeiger des Objekts automatisch in einen Verweis auf das Objekt umgewandelt, und es wird die Funktion verwendet, die das Objekt als Verweis akzeptiert.
Kann ich irgendwo etwas über die Richtung der impliziten Konvertierung von Referenzen und Zeigern lesen? Wird insbesondere auch die umgekehrte Umwandlung durchgeführt - von einer Referenz zu einem Zeiger?

- www.mql5.com
Verstehe ich das richtig, dass wir nach dem aktuellen Quelltext des Beispiels einen "Rake" bekommen, dass es im Objekt einer Form eines bestimmten Typs zwei Typvariablen gibt, zum Beispiel CLine::type zusätzlich zu CShape::type? Idealerweise sollte es nur eine geben - von der Basisklasse.
Ja, Sie haben recht. Es gibt zwei Typvariablen in jedem Abkömmling, wie Sie geschrieben haben. Das ist so passiert, weil der Code der Nachkommen kopiert wurde. Um ein Mitglied der Basisklasse direkt für Nachkommen verfügbar zu machen, sollte es mit dem Spezifizierer protected definiert werden oder es sollten öffentliche get- und set-Methoden für dieses Mitglied in der Basisklasse deklariert werden.
Zum Beispiel wie folgt:
//+------------------------------------------------------------------+ //|demo_Vererbung.mq5 | //| Copyright 2010, MetaQuotes Software Corp. | | //|http://www.mql5.com | //+------------------------------------------------------------------+ #property copyright "2010, MetaQuotes Software Corp." #property link "http://www.mql5.com" #property version "1.00" //+------------------------------------------------------------------+ //|| //+------------------------------------------------------------------+ class CBase { private: int type; public: CBase(){type=0;} int GetType(){return(type);} }; //+------------------------------------------------------------------+ //|| //+------------------------------------------------------------------+ class CSon: CBase { private: int type; public: CSon(){type=2;} void PrintType(); }; //+------------------------------------------------------------------+ //|| //+------------------------------------------------------------------+ void CSon::PrintType() { Print("CSon.type =",type); Print("CBase.type =",CBase::GetType()); } //+------------------------------------------------------------------+ //| Skript-Programmstartfunktion| //+------------------------------------------------------------------+ void OnStart() { //--- CSon son; son.PrintType(); int father_type=son.GetType(); } //+------------------------------------------------------------------+
"Dieses Beispiel ist sehr einfach, es ist nicht schwer, einen Fehler darin zu finden. Aber wenn Ihr mql5-Programm Hunderte oder gar Tausende von Zeilen enthält, kann das Auffinden solcher Fehler viel komplizierter werden. Insbesondere dann, wenn die Bedingungen für abnormale Situationen im Programmverhalten von unvorhersehbaren Faktoren abhängen - zum Beispiel von einem bestimmten Markt."
Wie?:-)

- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Verwendung von Objektzeigern in MQL5 :
In MQL5 werden alle Objekte standardmäßig per Verweis übertragen, doch gibt es eine Möglichkeit, Objektzeiger zu verwenden. Dazu muss jedoch eine Prüfung des Zeigers durchgeführt werden, da das Objekt u.U. nicht initialisiert ist. In diesem Fall wird das MQL5-Programm mit schwerwiegendem Fehler beendet und entladen. Die automatisch erzeugten Objekte verursachen diesen Fehler nicht, sind in diesem Sinn also recht sicher. In diesem Beitrag versuchen wir den Unterschied zwischen Objektverweis und Objektzeiger zu erklären und werfen einen Blick darauf, wie man sichere Codes schreibt, die diese Zeiger verwenden.
Autor: MetaQuotes Software Corp.