Fragen von Anfängern MQL5 MT5 MetaTrader 5 - Seite 192

Neuer Kommentar
 

Ich habe begonnen, OOP zu lernen und kann das folgende Hindernis nicht überwinden. Das folgende Skript ist ein Beispiel:

CSum result;
void OnStart()
  {
//---
  }
//+----------------------------------------+
class CSum
  {
public:
   int               Calculate(int A,int B);
  };
//---
int CSum::Calculate(int A,int B)
  {
   return(A+B);
  }

Ohne die Zeile "CSum result;" wird der Compiler keinen Fehler erzeugen. Aber es verursacht einen Fehler:

Sag mir, was los ist. Ich scheine das Klassenobjekt richtig deklariert zu haben.

 
paladin800:

Ich habe begonnen, OOP zu lernen und kann das folgende Hindernis nicht überwinden. Das folgende Skript ist ein Beispiel:

Ohne die Zeile "CSum result;" wird der Compiler keinen Fehler erzeugen. Aber es verursacht einen Fehler:

Bitte sagen Sie mir, was los ist. Ich scheine das Klassenobjekt richtig deklariert zu haben.

Eine Variable vom Typ CSum (Ergebnis) wird deklariert, bevor die Beschreibung von CSum abgeschlossen ist, was bedeutet, dass der Compiler diesen Typ noch nicht kennt. Fügen Sie CSum ganz am Anfang der Datei ein.
 
Lone_Irbis:
Wie sehr kann/sollte das System der globalen Variablen ausgenutzt werden? Ist es möglich, etwas auf diese Weise zu überlasten, oder gibt es eine Grenze? Sagen wir zum Beispiel, zwei oder mehr Hunderte von Variablen (von denen etwa die Hälfte zu Input und zurück werden, je nachdem, welcher Teil des Codes getestet werden muss) und etwa anderthalb Dutzend kleine Arrays auf globaler Ebene - ist das viel oder wenig? ^^' Und was ist, wenn es zwei- oder dreimal mehr von ihnen gibt, während das System fertiggestellt wird? Und wenn wir es nicht übertreiben wollen: Gibt es eine einfachere Möglichkeit, den Datenaustausch zwischen einem Dutzend verschiedener Teilsysteme zu handhaben, von denen viele die Ergebnisse der anderen benötigen?
Nein, die gibt es nicht. Globale Variablen werden für andere Zwecke verwendet. Verwenden Sie Klassen zur Beschreibung von Teilsystemen. Und die Verwendung von Arrays und globalen Variablen sollten Sie besser ganz vermeiden.
 
C-4:
Eine Variable vom Typ CSum (Ergebnis) - wird deklariert, bevor die CSum-Beschreibung erfolgt ist, was bedeutet, dass der Compiler diesen Typ noch nicht kennt. Fügen Sie CSum ganz am Anfang der Datei ein.
Ups, es hat geklappt. Ich habe die Klasse am Ende des Codes platziert, in Analogie zur Platzierung von Funktionen. Ich hatte nicht erwartet, dass eine solche Reihenfolge für eine Klasse einen Unterschied machen würde.
 
paladin800:
Ups, es hat geklappt. Ich setze die Klasse an das Ende des Codes, ähnlich wie bei der Platzierung von Funktionen. Ich hatte nicht erwartet, dass eine solche Bestellung einen Unterschied für die Klasse machen würde.
Ja, leider spielt die Rangfolge eine Rolle. Am schwierigsten ist es, wenn zwei Klassen gleichzeitig aufeinander zugreifen. Unabhängig davon, welche Klasse wir zuerst einführen, wird die zweite Klasse dem Compiler unbekannt sein und einen Fehler verursachen. In diesem Fall können Sie auf eine Klassendeklaration nicht verzichten. In Ihrem Fall ist es besser, CSum in eine separate Datei auszulagern, z. B. Sum.mqh, und sie mit der Anweisung #include "Sum.mqh" einzubinden.
 
C-4:
Nein, das sollten Sie nicht. Globale Variablen werden für andere Zwecke verwendet. Verwenden Sie Klassen zur Beschreibung von Teilsystemen. Und es ist besser, Arrays und globale Variablen überhaupt nicht zu verwenden.
Natürlich verstehe ich, dass es eine gute Idee, Klassen zu verwenden, aber ich bin immer noch irgendwie faul, wenn man bedenkt, dass es mehr vertraut ist, ohne sie, und sie scheinen in jedem Fall zu arbeiten. Aber ich bin einfach neugierig, was ist ihr Vorteil? Vorausgesetzt, man weiß mit Sicherheit, dass der Code von einem Autor ausschließlich für sich selbst geschrieben wurde und niemals außerhalb eines bestimmten Programms von Nutzen sein wird? Es hatte immer den Anschein, dass Kurse nur dann Sinn machen, wenn man für jemanden/etwas/einen Verkauf schreibt, während sie für einen selbst als Hobby keinen großen Unterschied machen. Abgesehen von der Ästhetik und dem allgemeinen "so-so", ist es sinnvoll, sich in all diesen Klassen-Strukturen zu engagieren? Geschwindigkeit? Sonst noch etwas?
 
Lone_Irbis:
Natürlich verstehe ich, dass es schön wäre, mit Klassen umzugehen, aber ich bin immer noch zu faul, wenn man bedenkt, dass es ohne sie vertrauter ist, und sie scheinen sowieso zu funktionieren. Aber ich bin einfach neugierig, was ist ihr Vorteil? Vorausgesetzt, man weiß mit Sicherheit, dass der Code von einem Autor ausschließlich für sich selbst geschrieben wurde und niemals außerhalb eines bestimmten Programms von Nutzen sein wird? Es hatte immer den Anschein, dass Kurse nur dann Sinn machen, wenn man für jemanden/etwas/einen Verkauf schreibt, während sie für einen selbst als Hobby keinen großen Unterschied machen. Abgesehen von der Ästhetik und dem allgemeinen "so-so", ist es sinnvoll, sich in all diesen Klassen-Strukturen zu engagieren? Geschwindigkeit? Etwas anderes?

Im Gegenteil. Wenn Sie ein kundenspezifisches Projekt schreiben, verlangt der Kunde oft den Quellcode. Und dann müssen Sie Funktionen aus Klassen ziehen und in den Quellcode einfügen. Es ist besser, dem Kunden eine einzige Datei zu geben, als einen Berg von Bibliotheken mitzuschleppen, die eine große Anzahl von Funktionen enthalten, die in der an den Kunden übergebenen Arbeit nicht verwendet werden. Das heißt, es ist besser, die strukturierte Programmierung nach Bedarf zu nutzen.

Für Ihre eigenen Bedürfnisse ist es besser, OOP zu verwenden - dort ist alles autark und Sie müssen sich nicht um die Weitergabe des Quellcodes kümmern.

 
artmedia70:

Im Gegenteil. Wenn Sie ein benutzerdefiniertes Projekt schreiben, benötigt der Kunde oft den Quellcode. Und dann müssen Sie Funktionen aus Klassen ziehen und in den Quellcode einfügen. Es ist besser, dem Kunden eine einzige Datei zu geben, als einen Berg von Bibliotheken mitzuschleppen, die eine große Anzahl von Funktionen enthalten, die in der an den Kunden übergebenen Arbeit nicht verwendet werden. D.h., es ist besser, für einen Kunden strukturierte Programmierung zu verwenden.

Es ist besser, OOP für den eigenen Bedarf zu verwenden - alles ist vorhanden, und man muss sich nicht um die Übertragung des Quellcodes kümmern.

Hmmm... Na ja, vielleicht schon :) Das Prinzip sieht natürlich verlockend aus... in der Theorie. Vor allem, wenn man bedenkt, dass ich keine einzige Datei ohne Strukturen oder Klassen erstellen kann. Die Sache ist die, dass ich hauptsächlich aus Interesse schreibe, meine eigenen zufälligen Theorien teste und endlose Fahrräder erfinde. Parallel dazu untersuche ich nur, was für die Umsetzung der Idee erforderlich ist. All dies geschieht im Rahmen eines einzigen lernenden und experimentellen Expert Advisors - anfangs ein einfacher Martin, aber jetzt ist er eher ein multifunktionaler Scalper im Entstehen (und bereits theoretisch profitabel). Irgendwann wurde der Roboter also trivialerweise zu groß. >Als ich die meiste Zeit damit verbracht habe, mit dem Mausrad zu scrollen, um den richtigen Code zu finden, hatte ich die "geniale" Idee, ihn in separate Dateien aufzuteilen (derzeit 13 Teile, die miteinander verbunden werden können) und die Funktionen einfach nach ihrem allgemeinen Konzept zu gruppieren. Wie z.B. News-Parser hier, Level-Verarbeitung dort, ein anderer mit Elch-Controllern, Statistiken separat, usw. Aber zu dieser Zeit war mein Enthusiasmus für OOP noch nicht groß genug...

Mein Problem scheint also zu sein, dass ich einfach jede Idee aufgreife, die mir einfällt, und sie auf einen bestehenden Roboter aufbaue... chaotische Abfolge. Das Ergebnis ist ziemlich bizarr, mit allen möglichen Schaltern und Kombinationen von Modi, von denen viele nicht ausgeführt werden. Ergänzt wird das Ganze durch hundertfünfzig globale Variablen, die aus den Eingaben entfernt werden müssen, um nicht so viel Zeit zu beanspruchen, und die zu Beginn in den Visualizer des Testers eingeblendet werden. Dazu kommen natürlich Berge von Müll und Rudimente von aufgegebenen oder umgestalteten Ideen.

Und es scheint ein guter Zeitpunkt zu sein, um diesen ganzen Haufen Müll zu sortieren und alles in Klassen einzuteilen (und erst einmal mindestens einen Artikel über OOP zu lesen, ohne dabei einzuschlafen)... Aber ich bin verwirrt über den Umfang der zu leistenden Arbeit und, ähem, ihr Verhältnis zum möglichen Sinn des Ganzen. Das heißt, alle in Klassen abzuschließen - es scheint nicht so voluminöse Aufgabe... Aber würde es Sinn machen, wenn man z.B. alles in einer Reihe in die Öffentlichkeit kippt und all diese privaten/geschützten ignoriert? Was ist daran besser als ein Ordner mit einem Haufen .mphs und jeweils einem Dutzend gemeinsamer Funktionen, wenn sie sowieso alle in einem Roboter landen?

 
Lone_Irbis:

Ich würde Ihnen raten, eine einzige Vorlage zu erstellen, die bereits alle notwendigen Schritte für die Initialisierung, die Verbindung, die Erfassung der stets benötigten Daten usw. enthält.

Eine unerwartete Idee kam mir in den Sinn: Ich lade eine Vorlage, benenne sie um und schreibe nur das hinein, was für diese spezielle Idee relevant ist. Und die Funktionen, die Sie in jedem Code immer wieder verwenden und die in jeder Situation dieselben Daten zurückgeben, sollten Sie in Klassen unterbringen. Und alles wird sich auf einmal fügen. Sie können auch Verzeichnisse strukturieren. In \experts\ erstellen Sie (bei mir ist das so) den Ordner Aufträge, in dem ich auch alle Dateien, die zu verschiedenen Kunden gehören, in separaten Ordnern ablege, es gibt einen Ordner Ideen, Tests, usw.

Auf diese Weise können Sie für Ordnung sorgen.

 
Leider werden Sie auch durch das formale Erlernen von OOP nicht in der Lage sein, ein OOP-Programm zu erstellen. Vielmehr müssen Sie sich mit der Philosophie dieses Ansatzes auseinandersetzen, und das ist die nächste Stufe nach dem Erwerb formaler Kenntnisse. Es stellt sich also heraus: Brauchen Sie das wirklich? Wenn Sie aber Fragen stellen, wie man es besser machen kann, bedeutet das, dass Sie das Gefühl haben, dass der von Ihnen gewählte Weg nicht optimal ist. In jedem Fall haben Sie die Wahl.
1...185186187188189190191192193194195196197198199...1504
Neuer Kommentar
Grund der Beschwerde: