Wird OOP in MQL5 gefragt sein? - Seite 6

 

Wenn Sie wollen, können Sie OOP auch in BASIC finden, das ebenfalls ein Interpreter ist.


Ich denke, wir müssen abwarten und sehen, wie viel OOP in Indikatoren, Expert Advisors und Skripten gefragt sein wird. Und auf die Tatsache zu entscheiden, wie es wirklich ist.

 

HideYourRichess писал(а) >>

Ich denke, wir sollten abwarten und sehen, wie sehr OOP in Indikatoren, EAs und Skripten gefragt sein wird. Und dann entscheiden, wie es tatsächlich funktioniert.

Im Moment versuche ich, das Kopieren von Datenpuffern mit allen Indikatoren zu automatisieren. Es ist ein schwieriger Prozess, ich stehe immer vor solchen Problemen wie dem Fehlen von Referenzen, Konstruktoren mit Parametern (RAII ist nicht realisierbar), usw.

Und ich bin nicht zufrieden mit einer ähnlichen Sache, die damit einhergeht. Ganz und gar nicht.

C-4 schrieb >>

Z.U. Die meisten Menschen assoziieren OOP mit einer bestimmten Programmiersprache C++

Warum, ist sie schlecht umgesetzt? Imho recht gut umgesetzt. Wie in jeder anderen normalen objektorientierten Sprache.

MQ5 ist ein OOP,

Aber es ist arm an Funktionen.

OOP gibt es sogar in C, aber aus irgendeinem Grund wissen viele nichts davon, was wiederum von oberflächlichem Wissen zeugt.

Bitte erläutern Sie diesen Punkt etwas genauer.

 
TheXpert >> :

Jetzt versuche ich, das Kopieren von Pufferdaten mit allen Begleitdaten in den Indikatoren zu automatisieren. Es wird schwierig, es ist kompliziert, ich stoße ständig auf Mauern wie fehlende Referenzen, Konstruktoren mit Parametern (RAII ist nicht realisierbar), usw.

Und ich bin nicht zufrieden mit einer ähnlichen Sache, die damit einhergeht. Ganz und gar nicht.

Um ehrlich zu sein, habe ich das auch versucht. Es war nichts Besonderes, nur ein kleiner Versuch. Ich habe es aufgegeben, es hat mir nichts Gutes gebracht. Entweder muss ich eine Menge umlernen, oder das OOP muss erweitert werden. Beide werden noch nicht erwartet. Im Allgemeinen ging ich über die Harke, und verstand nicht, ob ich so ein Narr war oder ob ich Tickets an den technischen Support schicken sollte, - ich gab alles vorläufig auf.

 

Bitte, ich kann das näher erläutern:

INKAPSULIERUNG:

struct mail

{

int zipcode;

char adr[50];

char comment[10];

...

}

Das bloße Vorhandensein von Strukturen ist eine ungeschützte Verkapselung.

STATISCHER POLYMORPHISMUS:

double d=3.12, c;

int i=5;

c=d+i;

(Verschiedene Datentypen werden durch denselben Operator summiert)

DYNAMISCHER POLYMORPHISMUS:

void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));

Die Funktion qsort verhält sich unterschiedlich, abhängig von der Art der Vergleichsunterfunktion

INKUBATION:

Gleiches Beispiel wie bei der dynamischen Polymorphie, in diesem Fall übernimmt die Funktion qsort gewissermaßen die Eigenschaften von compare()

 
C-4 >> :

Bitte, ich kann das näher erläutern:

So etwas hatte ich eigentlich erwartet. Nur statischer Polymorphismus wird gezählt. Ich sehe keinen Sinn darin, die Diskussion über dieses Thema (OOP in C) fortzusetzen und werde es auch nicht tun.

Ich dachte, du würdest mich wirklich überraschen.

 
Wenn Sie so etwas wie das klassische Überladen von Funktionen usw. sehen wollen, laden Sie einen modernen C-Compiler herunter, z. B. LCC, und sehen Sie nach. Das LCC unterstützt zum Beispiel die klassische OOP, auch wenn dies nicht zum Standard gehört.
 

Um einige sehr vorläufige Ergebnisse zusammenzufassen, können wir sagen, dass OOP bei der Implementierung von Meta-Quotes selbst von erfahrenen Programmierern nicht akzeptiert wird. Vielleicht liegt es an der Umsetzung. Vielleicht wird man sich daran gewöhnen müssen und das OOP wird wirklich bequemer werden. Aber bis jetzt haben wir, was wir haben. Es scheint ohne sie bequemer zu sein. D.h. Sie können es wahrscheinlich schreiben, aber nur für OOP, nicht für die Benutzerfreundlichkeit, Geschwindigkeit des Schreibens, ganz zu schweigen von der Leistung des Codes selbst, die sowieso langsamer gegen PP sein wird.

Das ist der Fall...

 

Ist die Notwendigkeit von OOP wirklich so wichtig (egal, wer sich darunter versteht)? Für mich ist es viel wichtiger, welche neuen Handels- und Servicefunktionen auftauchen werden, die die Arbeit von Händlern und Programmierern erleichtern, und wie gut/vollständig sie implementiert werden.

Zeigen Sie mir mindestens zehn Zertifikate über die Übereinstimmung von MQL5 mit den OOP-Standards, aber ohne die Erstellung von Objekten durch Indikatoren wird Sie kein OOP vor den Komplikationen bei der Anzeige von einfachem Text auf dem Bildschirm retten. Was nützt ein stolzer Einsatz von OOP, wenn man nicht einmal ein gewöhnliches Handrad in diesem Chart-Objekt verwenden kann? Eine Schaltfläche, die als Kontrollkästchen funktioniert, und das Fehlen eines Standard-Kombinationsfeldes, so dass man z.B. in einem Expert Advisor einfach den Zeitrahmen für die Berechnungen auswählen könnte, und die Möglichkeit, mehrere Objekte in einem zu gruppieren. Ich spreche nicht einmal vom Editor der Dialogformulare, denn die Plattform ist für den automatischen Handel entwickelt worden... :(

IMHO: In MQL5 gibt es nur eine (stark) verkürzte Version der Möglichkeiten, die in der klassischen OOP stecken. Die Entwickler haben großartige Arbeit geleistet und es vereinfacht sicherlich das Schreiben eines Quellcodes, aber es ist alles umsonst, und ich will immer noch ein Taxi, und ich hoffe, dass die Entwickler nicht bald mit der Arbeit an MQL6 beginnen, sondern lange und fruchtbar an der "Fertigstellung" von MQL5 arbeiten werden ;)

 
ForexTools >> :

Aber ist die Forderung nach OOP so wichtig (wer auch immer dieses Akronym versteht)? Für mich ist es viel wichtiger, welche neuen Handels- und Servicefunktionen erscheinen werden, die die Arbeit des Händlers und des Programmierers erleichtern, und wie gut/vollständig sie implementiert werden.

Ja, natürlich. Und darüber wurde in den entsprechenden Threads schon viel gesagt. Ich habe zum Beispiel den Eindruck, dass MC, anstatt alte Probleme zu lösen, deren Lösung durch Innovationen nur noch komplizierter gemacht hat.

Ich spreche jetzt nicht von OOP. Aber die Energie, die für diese Funktion aufgewendet wurde, hätte man auch für etwas wirklich Nützliches und Gefragtes verwenden können.

 
Svinozavr >> :

Ja, natürlich. Und in den einschlägigen Threads wurde schon viel darüber gesagt. Ich habe zum Beispiel den Eindruck, dass der MC, anstatt die alten Probleme zu lösen, sie nur noch schwieriger gemacht hat, indem er neue eingeführt hat.

Ich meine jetzt nicht die PLO. Aber die Energie, die man für diese Gelegenheit aufwendet, könnte man durchaus für etwas wirklich Nützliches und Gefragtes verwenden.

Das ist wirklich keine einfache Frage. In der Tat. Wir sehen keine Umgestaltungen auf dem Server. Lückenhaften Informationen im Internet zufolge ist es kühler als es war. Das alles ist sicherlich nicht für uns, für die Ärzte, aber auf der anderen Seite kann sich der Service im Allgemeinen verbessern.