OOP, Vorlagen und Makros in mql5, Feinheiten und Anwendungen - Seite 6

Neuer Kommentar
 
Alexey Viktorov:

Jetzt geht's los.

Alle Ihre Codes werden also auf Krücken erstellt? Es ist nichts Persönliches.
Ja, ungefähr so. Denn MQL hat kein vollwertiges OOP. Außerdem gibt es eine Menge Bugs, die ich regelmäßig melde, aber ohne Erfolg. Und gegen Bugs muss ich mich mit Krücken wehren, was soll ich machen.
 

So machen wir es.

Wenn eine statische Variable mit einer Konstanten initialisiert wird, dann wird diese Initialisierung in der globalen Initialisierungsphase durchgeführt, wie zuvor
Andernfalls (Aufruf oder Variableninitialisierung) wird eine statische Variable beim ersten Aufruf initialisiert (wie in C++), dieser Aufruf selbst wird in eine Bedingung mit impliziter globaler Variable/Flag verpackt, zum Beispiel

für MQL-Code:

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Es wird der folgende Pseudocode erzeugt

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov:

Sie müssen sie trotzdem irgendwie in der Funktion trennen.

Nicht unbedingt und nicht immer. Ich werde keine Beispiele nennen, um das Thema nicht zu überfrachten.

 
Ilyas:

So werden wir es machen.

Gute Nachrichten: Die Götter haben unsere Gebete erhört).
 
Alexey Navoykov:
Ja, ungefähr so. Denn MQL hat kein vollwertiges OOP. Außerdem gibt es eine Menge Bugs, die ich regelmäßig melde, aber ohne Erfolg. Und gegen die Bugs muss ich mich mit Krücken wehren, was soll ich machen.

Du bringst mich ganz durcheinander. Wenn in ... Ihre Worte lesen

Forum für Handel, automatisierte Handelssysteme und Strategietests

Eigenheiten von mql5, Tipps und Tricks

Alexey Navoykov, 2019.01.25 11:44

Wenn die Parameter von verschiedenen Typen sind, ist es sinnvoll, mehrere überladene Methoden mit den entsprechenden Typen zu machen. Man muss sie sowieso in Funktionen teilen, also ist es besser, sie in separate Funktionen aufzuteilen, als ein Durcheinander zu machen, das außerdem einen unpersönlichen Typ nimmt, d.h. man kann versehentlich alles übergeben und einen Kompilierungsfehler innerhalb der Bibliothek bekommen, was nicht gut ist. Oder vielleicht nicht einmal bekommen, was doppelt schlecht ist).

Kurz gesagt, in vollwertiger OOP sind Template-Funktionen eine Krücke (mit wenigen Ausnahmen).

Und es gibt kein vollwertiges OOP in MQL... Es fehlen sogar Krücken? Ich verstehe überhaupt nichts mehr.
 
MQL ist ganz gut mit OOP, und wenn Mehrfachvererbung hinzugefügt wird (zumindest für Schnittstellen, weil sie in ihrer aktuellen Form nutzlos sind), wird es perfekt sein.
 
Ilya Malev:
MQL ist OK mit OOP, wenn sie Mehrfachvererbung hinzufügen(zumindest für Schnittstellen, weil sie in ihrer aktuellen Form nutzlos sind), wird es perfekt sein.

Schnittstellen sind also die Grundlage der normalen OOP, und Sie sagen, dass in MQL alles in Ordnung ist.

 
Alexey Navoykov:

Schnittstellen sind also die Grundlage der normalen OOP, und dennoch sagen Sie, dass in MQL alles in Ordnung ist.

Die Grundlage der normalen OOP ist Polymorphismus, nicht Schnittstellen. Schnittstellen sind die Grundlage für eine bestimmte Klassenstruktur. Im Allgemeinen würde ich gerne über diese Themen sprechen, aber ich fürchte, dieser Thread ist nicht der richtige Ort dafür.

 
Ilya Malev:

Die Grundlage der normalen OOP ist Polymorphismus, nicht Schnittstellen. Schnittstellen sind die Grundlage für eine bestimmte Klassenstruktur. Generell würde ich mich freuen, diese Themen zu diskutieren, aber ich fürchte, dieser Zweig ist dafür nicht geeignet.

Wir sprechen hier über die Besonderheiten der MQL-Sprache, und das Fehlen von Mehrfachvererbung ist ein recht charakteristisches Merkmal).

Ok, die Grundlage ist natürlich der Polymorphismus, aber ohne separate Schnittstellen ist er in der Anwendung nicht praktisch. Dies führt häufig zur Übergabe von Objekten als Template-Argumente anstelle von Schnittstellen.

Ich habe hier meine Variante beschrieben, mehrere Schnittstellen zu simulieren. Demnach kann eine Klasse deklariert werden als

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov:

Wir diskutieren über die Besonderheiten der MQL-Sprache, und das Fehlen der Mehrfachvererbung ist eine Besonderheit).

Ok, die Basis ist sicherlich Polymorphismus, aber ohne getrennte Schnittstellen ist es in der Anwendung nicht praktisch. Dies führt häufig zur Übergabe von Objekten als Template-Argumente anstelle von Schnittstellen.

Meine Variante, mehrere Schnittstellen zu imitieren, habe ich hier beschrieben. Entsprechend kann eine Klasse als solche deklariert werden:

Meiner Meinung nach ist nicht alles schlecht. Es gibt nicht so viele grundlegende Hauptschnittstellen in C#, dass ihre Methoden nicht auf eine grundlegende Oberklasse reduziert und dann vererbt werden könnten.

P.S. Etwas mehrfaches durch Konstruktionen wie <<<<>>>> zu implementieren ist ein bisschen mühsam. Es ist besser, Funktionen über Operatoren auszuführen, z. B. a==b ruft a.compareto( b ) auf, a[comparer]==b ruft comparer.compare(a,b) auf usw.
12345678910111213...28
Neuer Kommentar