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

Neuer Kommentar
 
Ilya Malev:

Ich bekomme "Stack Overflow" )

Ich schätze, es ist doch eine Kakerlake...

Nun, es liegt nicht am Compiler, sondern an der Laufzeit. Der Compiler sollte reagieren.

Hier ist, was ich in VS 2010 versucht:

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

Ich erhalte einen Kompilierungsfehler: Fehler 1 Fehler LNK2001: nicht aufgelöstes externes Symbol "public: virtual __thiscall A::f2(void)".

Aber Metaeditor sagt kein Wort dazu. Nicht gut.

 
Es stellt sich heraus, dass der Aufruf einer Vorgängerfunktion mit = 0 zu einem Selbstaufruf wird. Wenn Sie diesen Fehler selbst entdecken, können Sie vielleicht davon profitieren...
 
Alexey Navoykov:

So sollte der Compiler reagieren.

Ich habe dies in VS 2010 versucht:

Ich erhalte einen Kompilierungsfehler: Fehler 1 Fehler LNK2001: nicht aufgelöstes externes Symbol "public: virtual __thiscall A::f2(void)".

Metaeditor sagt kein Wort dazu. Nicht gut.

Alexey, bitte erkläre mir, warum, wenn mql eine Kopie von C ist, es absolut identisch sein muss und ein Schritt nach links, ein Schritt nach rechts - Erschießungskommando?

Nur weil die Entwickler unvorsichtig waren? Aber jede Sprache ist auf Schleifen und Bedingungen aufgebaut. Alles andere steht im Trailer. Warum verlangt niemand, dass irgendeine andere Sprache C im OOP-Teil oder in irgendeiner anderen Weise ähnlich ist?

 
Alexey Viktorov:

Alexey, kannst du mir bitte an den Fingern erklären, warum, wenn mql wie C ist, dann muss es absolut identisch sein und einen Schritt nach links, einen Schritt nach rechts - Erschießungskommando?

Nur weil die Entwickler unvorsichtig waren? Aber jede Sprache ist auf Schleifen und Bedingungen aufgebaut. Alles andere steht im Trailer. Warum verlangt niemand, dass irgendeine andere Sprache C im OOP-Teil oder in irgendeiner anderen Weise ähnlich ist?

Es geht nicht darum, völlig identisch zu sein. Es geht darum, dass die Funktionalität, die implementiert wird, korrekt und konsistent funktionieren muss. Aber zuerst schreien Sie: Zeigen Sie mir eine andere Sprache, die anders funktioniert. Und wenn dann C++, das anders (korrekt) funktioniert, als Beispiel genannt wird, fangen Sie an, darüber zu schimpfen, dass MQL nicht C++ ist und nicht identisch sein sollte. Sie sollten sich entscheiden
 
Alexey Viktorov:

Können Sie uns ein Beispiel zeigen, in dem all dies das Schreiben von Code einfacher macht, ihn verkürzt oder zumindest vor Fehlern schützt? Und bitte keine abstrakten Funktionen, sondern Funktionen, die den realen Handelsbedingungen in einem Expert Advisor oder Indikator nahe kommen.

Niemals. Die Jungs versuchen nur, ihre Fantasien in die Realität umzusetzen.

 
Dmitry Fedoseev:

Niemals. Die Jungs versuchen nur, ihre Fantasien in die Realität umzusetzen.

Es scheint mir eine sehr nützliche Übung zu sein, die Fantasie in die Realität zu übertragen. Das ist der Sinn der Entwicklung!
Eine sehr erhellende Diskussion. (Vielen Dank.
 
Alexey Navoykov:

Ja, aber ich verwende seit langem eine alternative Option: Alle Schnittstellen sind ursprünglich als Zwischenvorlagenklasse konzipiert:

Auf diese Weise können Sie eine Vererbungskette erstellen, die aus einer beliebigen Anzahl solcher Schnittstellen besteht. Ja, natürlich kann man mit ihnen nicht dynamic_cast machen, aber das ist nicht so oft notwendig. Die Hauptaufgabe ist, sie in Funktionen zu übergeben.

Ich habe es aufmerksam gelesen, es ist übrigens ein interessanter Schritt. Daran hatte ich vorher nicht gedacht =) Ich werde auch experimentieren, wenn ich Zeit habe...

 
Nikolai Semko:
Für mich ist das eine sehr nützliche Übung - die Fantasie auf die Realität zu dehnen. Das ist der Sinn der Entwicklung!
Eine sehr erhellende Diskussion. Ich danke Ihnen.

Die Entwickler haben uns erhört und beschlossen, diesen Fehler zu beheben, über den alle seit Jahren stolpern.

Erstaunlich ist allerdings die destruktive Haltung mancher Forumsteilnehmer, die sich selbst nicht weiterentwickeln und mit bemerkenswerter Hartnäckigkeit versuchen, andere zu behindern.

 

>> Ja, natürlich können Sie nicht tun dynamic_cast mit ihnen, aber es ist nicht so eine häufige Notwendigkeit.

Warum tun Sie es nicht, kein Problem ) Aber dann taucht Ihr größter Albtraum auf - die Nichterkennung von Casting-Fehlern in der Kompilierungsphase :)

 
Ilya Malev:

>> Ja, natürlich können Sie nicht tun dynamic_cast mit ihnen, aber es ist nicht so eine häufige Notwendigkeit.

Warum tun Sie es nicht, kein Problem ) Aber dann erscheint Ihr größter Albtraum - die Nichterkennung von Gussfehlern beim Kompilieren :)

Schließlich könnte die Vererbungskette beliebig sein: Interface<CBase> oder Interface<C<B<A<CBase>>>>, es gibt unzählige Varianten. Wir müssten CBase konsequent auf alle möglichen Varianten casten, was unrealistisch ist.

Ich erinnere mich an die Planung zu implementieren Speicherung von Informationen über Schnittstellen in der Klasse Objekt selbst, und zusätzlich zu den bestehenden Schnittstelle Pads, machen unabhängige Schnittstelle Klassen, die als Wrapper über unsere Pad arbeiten würde. Doch dann kam ich zu dem Schluss, dass all dies unnötig und überflüssig war. In der Praxis habe ich noch nie eine Notwendigkeit gesehen, eine Basisklasse auf eine Schnittstelle zu casten, es macht einfach keinen Sinn. Die einzige Möglichkeit ist, herauszufinden, ob die Klasse diese Schnittstelle zu Debugging-Zwecken unterstützt, aber dafür brauchen wir kein Casting.

12345678910111213141516...28
Neuer Kommentar