MQL5 Der Compiler unterscheidet nicht zwischen einer Klasse und einem Zeiger auf sie - Seite 6
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Implizites Casting dieses Zeigers auf ein Objekt
Die korrekte Bezeichnung lautet "Implizite Zeigerdereferenzierung".
Ich unterstütze den Vorschlag, die implizite Dereferenzierung nur dann zuzulassen, wenn sie sich auf ein Klassenmitglied bezieht, z. B.:
Hier ist es das Gegenteil - ein Zeiger wird implizit in ein Objekt gecastet (dereferenziert) und dann wird operator= darauf angewendet. fxsaber hat es gestern auch erwähnt.
Obwohl dies logisch gesehen nicht im Widerspruch zu den MQL-Regeln steht (da der Aufruf von operator= gleichbedeutend mit dem Aufruf jeder anderen Objektmethode ist), führt dies zu Unklarheiten beim Verständnis eines solchen Codes und zu schwer zu findenden Fehlern. Und das betrifft nicht nur operator=, sondern auch == und !=. Vielleicht sollte ein solches Casting auch für andere Operatoren verboten werden, denn in C++ kann man auf Operatoren anwenden: +-<>[].
Die kurze Schlussfolgerung lautet: Wenn man Operatoren, die in C++ für Zeiger erlaubt sind, auf einen Zeiger anwendet, verbietet man ein implizites Casting dieses Zeigers in ein Objekt. Entsprechend würde das obige Beispiel einen Kompilierungsfehler aufweisen.
Ja, ich verstehe. Mit diesen einfachen Beispielen wollte ich allen Zweiflern zeigen, dass der Zeiger und das Objekt unterschiedliche Entitäten sind und man sie nicht verwechseln darf.
Und dieser Umstand erfordert zumindest einen bestimmten Stil beim Schreiben von Code, damit man keinen Fehler macht und Code erstellt, der kompiliert wird und sogar den Test besteht, aber unter realen Bedingungen versagt, was noch schlimmer wäre, wenn er für den Verkauf geschrieben wurde. Es wird nicht einfach sein, eine Fehlerstelle im Code zu finden, wo alles so "implizit" ist.
Eine Fehlerstelle in einem Code zu finden, in dem alles so "implizit" gleich ist, wird eine ziemliche Herausforderung sein.
Es wäre besser, wenn die Entwickler die Dinge so lassen würden, wie sie sind. Wenn sie jetzt wieder anfangen, die Sprache zu ändern, eine Reihe von Programmen nicht mehr kompilieren oder, noch schlimmer, nicht mehr wie erwartet funktionieren, wird es einen weltweiten Aufruhr geben.
Meiner Meinung nach sind Auto-Objekte in µl ein Rudiment, Unterzeiger mit eingeschränkten Funktionen (konstanter Zeiger mit Auto-Löschen), und sie müssen meist überhaupt nicht verwendet werden (außer für den Garbage Collector).
Es wäre besser, wenn die Entwickler die Dinge so lassen würden, wie sie sind. Wenn sie jetzt wieder anfangen, die Sprache zu ändern, eine Reihe von Programmen nicht mehr kompilieren oder schlimmer noch, nicht mehr wie erwartet funktionieren, wird es einen weltweiten Aufruhr geben.
Die Änderungen hier sind minimal. Es müssen lediglich Kompilierregeln zu folgenden Punkten hinzugefügt werden
so dass es nicht möglich ist, den Mist zu kompilieren, der jetzt als gut angesehen wird.
Damit Sie nicht die Art von Ketzerei zusammenstellen können, die heute als gut gilt.
wie A a = new A? Oder was genau ) wird jetzt von allen verwendet, so dass es keinerlei Auswirkungen hat
Wenn Sie aber A a, *b = a; schreiben, erhalten Sie einen Laufzeitfehler. In diesem Fall muss der Compiler explizit die Warnung "probable use of uninitialized variable 'b'" ausgeben, wie er es bei allen anderen Typen tut. Wenn es sich nicht um einen Kompilierungsfehler handelt. Aber nicht wegen der Zuweisung an sich, sondern wegen der Verwendung einer überladenen Funktion auf eine nicht initialisierte Variable, was natürlich einen Laufzeitfehler verursacht. Dies ist wirklich ein Fehler und scheint mit einer übermäßigen Codeoptimierung zusammenzuhängen.
Und im Allgemeinen ist es keine Ketzerei, Auto zu Dino und umgekehrt zuzuordnen, dies können nützliche Funktionen sein.
Aber ich würde so etwas wie das implizite Kopieren von Objekten ganz abschaffen. Obwohl es ein Standard in C++ ist. Das ist eigentlich der Grund für all diese Probleme.wie A a = new A? Oder was genau )
Nun, das versteht sich von selbst. Hier gibt es ein Speicherleck.
Aber im Allgemeinen ist es keine Ketzerei, Auto zu Dino und umgekehrt zuzuordnen, das können nützliche Funktionen sein.
Lass es sein. Aber ausdrücklich. Und ich werde es nicht aus Versehen tun, sondern weil ich es muss.
Nun, das ist eine Selbstverständlichkeit. Hier gibt es ein Speicherleck.
Wenn Sie ein Objekt auf der linken Seite haben, warum sollten Sie dann ein solches Konstrukt schreiben?
Aber die umgekehrte Situation, wenn Sie einem Zeiger etwas zuweisen und dieser plötzlich dereferenziert wird, ist ein nicht offensichtlicher Fehler.
Hier ist alles durcheinander, sowohl Fliegen als auch Schnitzel. Ich spreche von der Diskussion über das Thema.
Wenn Sie ein Objekt auf der linken Seite haben, warum schreiben Sie dann eine solche Konstruktion?
Der menschliche Faktor! Der Compiler sollte sie auf ein Minimum beschränken.
Der menschliche Faktor! Der Compiler sollte sie auf ein Minimum beschränken.