Auf Wiedersehen, Roboter - Hallo, Marasmus - Seite 11

 

Bezüglich des Ausblendens des Variablennamens:

simpleton schrieb bereits über intel compiler, ähnliche Situation mit gcc und clang. Beim Kompilieren in einem sehr strengen Modus (in Bezug auf das Vorhandensein von Nachrichten):

gcc(clang) -Wall -Wextra

beschwert sich der Compiler nicht über dieses Problem. Beschwerden über das Verstecken werden mit einer separaten Option -Wshadow- aktiviert. D.h. die Prüfung selbst ist auf C++-Compilern (außer MSVC) nicht schwierig. Aber ich habe keine Ide (basierend auf gcc, zum Beispiel, qt Creator, Code-Blöcke ...) gesehen, wo -Wshadow standardmäßig aktiviert ist.

Und warum? Wahrscheinlich, weil der Nutzen dieser Nachricht für die meisten Menschen fraglich ist.

 
Pavlick:

Bezüglich des Ausblendens des Variablennamens:

simpleton schrieb bereits über intel compiler, ähnliche Situation mit gcc und clang. Beim Kompilieren im sehr strengen Modus (in Bezug auf das Vorhandensein von Nachrichten):

Sie scheinen den irreführenden "strengen Compilermodus" mit der tatsächlichen Arbeit statischer Analysatoren zu verwechseln, da Sie diese nie benutzt haben.

Der Compiler schließt die Kompilierung in 1-2 Minuten ab, während die Analysatoren mehrere Stunden (PVS Studio) oder Dutzende von Stunden (CPP Check) an demselben Code arbeiten können. Daher auch die unterschiedliche Qualität und Tiefe der Ergebnisse.

 

Ich grüße alle.

Es ist fast ein Jahr her, dass die "Verrücktheit" und der Marasmus der Innovationen in MQL4 nicht aufgehört hat. "Aber es ist noch da! (с).

Früher haben sie "Metaquotes" für die schlechte Sprache verantwortlich gemacht, jetzt beschuldigen sie sie für zu viel "Wasser". Die Probleme haben sich nicht verringert.

Ich kann das Folgende von mir hinzufügen.

Für Händler, Nicht-Programmierer und unerfahrene Programmierer kann ein einfacher Algorithmus und Code implementiert werden.

Wenn Sie eine große Anzahl von Indizes, Eulen usw. haben, die sich in den neuen Builds nicht kompilieren lassen, ist es sinnvoll, genau hinzuschauen und Ihre Kassen aufzumischen". Achten Sie darauf, die nützlichsten Dinge zu speichern, und scheuen Sie keine Zeit, sie für neue Builds neu zu schreiben und zu debuggen.

Wirklich erfahrene Programmierer oder solche, die es werden wollen, verfolgen immer Innovationen, Bugs und Glitches sind ihr Brot. Es ist das Schreiben von Code ohne Fehler, das als gute Programmierung gilt. Wenn Sie nicht die Energie, die Zeit, die Möglichkeit oder den Wunsch haben, alle Neuerungen von "Metakvot" zu erfassen, verwenden Sie die Sprache, die Sie fließend beherrschen. Die DLLs wurden nicht abgeschafft, Sie können Ihre eigenen, fein abgestimmten Algorithmen einfügen.

 
Andrei01:

Testumgebungen werden häufig in Softwareprodukten zur funktionalen Überprüfung von Software-Chipdesigns eingesetzt, wobei die Anforderungen an die Codequalität sehr hoch sind. Darüber hinaus ist eine funktionale Hülle ein integraler Bestandteil jeder Chipdesign-Code-Entwicklung. Andererseits haben viele Programmierer beim Schreiben gewöhnlicher Softwareprojekte nicht einmal eine Vorstellung von solchen Funktionstests, weil das Schreiben solcher Tests von Grund auf mehr Zeit in Anspruch nehmen kann als das Schreiben des Projekts selbst und nur dann gerechtfertigt ist, wenn es erforderlich ist, qualitativ hochwertigen Code zu schreiben oder wenn es viele Versionen desselben Projekts gibt. Andererseits spart eine gekonnt geschriebene Testumgebung erheblich Zeit bei der Fehlersuche und der Codeüberprüfung.

Die statische Analyse wird ebenfalls verwendet, allerdings nur als sehr oberflächliche und erste Syntaxprüfung.

Testumgebungen sind Testumgebungen. Eine Testumgebung ist auf das zu testende Produkt "beschränkt".

Ich meinte allgemeine Werkzeuge - solche, die "keine Ahnung" von dem zu analysierenden Produkt haben und daher Probleme in jedem Produkt analysieren und finden können.

 
Renat:

Einfaltspinsel, was für ein Blödsinn.

"Was für ein Unsinn" scheint auf ein völliges Missverhältnis zwischen den Einstellungen hinzudeuten.

Renat:

Erst wenn Sie die Ebene der totalen Qualitätskontrolle erreicht haben, werden Sie sie verstehen. Solange Sie jedoch auf der Wahrnehmungsebene eines einzelnen egoistischen Programmierers bleiben, werden Sie weiterhin denken: "Es ist vernünftig, mich nicht zu kontrollieren, die Kontrolle wird von separaten, niemals laufenden Dienstprogrammen übernommen".

Warum also lässt die "totale Qualitätskontrolle" ein so niedriges Niveau der Qualitätskontrolle zu?

Zum Beispiel:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

Der Konstruktor wird aufgerufen, wenn ein Objekt in Methode2 erstellt wird:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Warum ist alles in Ordnung, wenn ein Objekt dynamisch erstellt wird, d.h. der private Konstruktor ist über die Objektmethode verfügbar, aber wenn das Objekt automatisch erstellt wird, ist der private Konstruktor plötzlich nicht mehr verfügbar?

Ich persönlich habe es aufgegeben, etwas Komplizierteres als Einfaches in MQL zu machen, weil es für mich sehr schwierig ist: Ich stoße immer auf etwas, das nicht funktioniert.

Aber mit C/C++-Compilern habe ich dieses Problem nicht.

Und das Problem "es ist vernünftig, mich nicht zu kontrollieren, lassen Sie die Kontrolle getrennt nie laufen Dienstprogramme" ist direkt mit der Psychologie verbunden. Hier muss die Psychologie korrigiert werden, damit der Programmierer sich selbst zwingen kann, anstatt zu versuchen, die Technologie an die Psychologie anzupassen, um diese Psychologie zu umgehen.

Ich denke mir das nicht aus, einige Dienstprogramme werden regelmäßig vor meinen Augen erfolgreich eingesetzt, und das Ergebnis ihrer Arbeit wird später auch erfolgreich zur Beseitigung von Fehlern verwendet.

Renat:

Fehler werden bekämpft, aber parallel dazu fügen wir vieles hinzu und verbessern es.

Vielleicht werden die Prioritäten auf Kosten der Qualität auf das Hinzufügen und Verbessern verlagert. Aber dann ist es nicht mehr eine totale Kontrolle darüber.

Renat:

Am Freitag wird es eine neue Version von MT4 geben, die deutliche Verbesserungen bei der Ausführungsgeschwindigkeit und beim Testen aufweist.

In diesem Fall meine ich die Verfügbarkeit von privaten Konstruktoren aus Objektmethoden nicht nur für den Fall der dynamischen Objekterzeugung - wird es irgendwelche Verbesserungen in der Sprachbedienbarkeit geben?

Renat:

Im Gegensatz zu C++ ist MQL absolut sicher (wenn es keine Ausgabe an die DLL gibt), da rohe Links abgelehnt werden und es sich im Allgemeinen um eine verwaltete Sprache handelt.

Ok, nehmen wir an, dass "C++ gefährlich und selbstmörderisch ist" und "MQL absolut sicher ist".

Warum sollte man eine Sprache als Grundlage für MQL nehmen, die so weit vom Kriterium der Sicherheit entfernt ist, dass man eine "absolut sichere" Sprache schaffen wollte, die genau auf der "gefährlichen und selbstmörderischen" Sprache basiert?

 
Pavlick:

OK?


Hallo, Pawlik!

Ich bin es wieder, Panza!

Ich habe Ihren Code getestet, um das Skript auf verschiedenen mt4 aufzurufen

und ich habe einige seltsame Dinge herausgefunden!

Ihr Code funktioniert gut auf MT4 build 670 von Pepperston

(Australien), aber es will nicht auf MT4 build 670 Alpari funktionieren!

user32.dll wirdauf alpariseltsamaufgerufen!

Die ersten 2 Dlls werden aufgerufen (obwohl dies nicht im Code stand!)

dann wirduser32.dllaufgerufen,aber es wird in eine Bibliothek geworfen!

aber Sie müssen es auch in der Bibliothek aufrufen!

Es scheint, dass Alpari mit dem Anruf zu kämpfen hat.

d.h. es liegt eine offensichtliche Code-Störung vor!

Ich füge 2 Bilder zum Vergleich bei!

Ich wünsche Erfolg!

Panza

oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"Was für ein Unsinn" - damit ist offenbar eine völlige Diskrepanz zwischen den Positionen gemeint.

Das bedeutet, dass jemand wissentlich mehr Erfahrung darin hat, die Veröffentlichung mehrerer Softwareprodukte für einen konkurrierenden Markt zu leiten.


Warum lässt die "totale Qualitätskontrolle" ein so niedriges Niveau der Qualitätskontrolle zu?

Es besteht keine Notwendigkeit, von der Diskussion allgemeiner Qualitätskontrollprinzipien zu den spezifischen Unzulänglichkeiten einer bestimmten Lösung überzugehen. Eine solche Methode ist inakzeptabel, denn es ist immer möglich, in jedem Produkt einen Fehler zu finden.

Zum Beispiel:

Der Konstruktor wird aufgerufen, wenn ein Objekt in Methode2 erstellt wird:

Warum ist alles in Ordnung, wenn ein Objekt dynamisch erstellt wird, d.h. der private-constructor ist über die Objektmethode verfügbar, aber wenn ein Objekt automatisch erstellt wird, ist der private-constructor plötzlich nicht mehr verfügbar?

Dies ist nur eine Folge des Überschutzes"statische Klassenmethode hat kein Recht, in den Klasseninhalt einzudringen". In diesem Fall muss die Zugangskontrolle jedoch gelockert werden.

Ich persönlich habe es aufgegeben, in MQL etwas zu tun, das etwas komplexer als einfach ist, weil es für mich sehr schwierig ist: Ich stoße immer auf etwas, das nicht funktioniert.

Nennen Sie mir ein funktionierendes Beispiel und nicht einen Fall von "Ich habe die Dinge absichtlich verdreht, Zugänge geschlossen und dann angefangen, an grenzwertiges Verhalten zu appellieren".


Mit C/C++-Compilern habe ich solche Probleme allerdings nicht.

Die Probleme dort sind anderer Art. Und sie sind wissentlich um Größenordnungen größer, wenn man bedenkt, dass man keine statischen Analysatoren verwendet.


Und das Problem "es ist vernünftig, mich nicht zu kontrollieren, lassen Sie die Kontrolle getrennt nie laufen Dienstprogramme" ist direkt mit der Psychologie verbunden. Hier muss die Psychologie korrigiert werden, damit der Programmierer sich selbst zwingen kann, anstatt zu versuchen, die Technologie an die Psychologie anzupassen, um diese Psychologie zu umgehen.

Ich denke mir das nicht aus, einzelne Dienstprogramme werden vor meinen Augen regelmäßig erfolgreich eingesetzt, und das Ergebnis ihrer Arbeit wird auch anschließend erfolgreich zur Fehlerbeseitigung genutzt.

Vielleicht werden die Prioritäten auf Kosten der Qualität auf das Hinzufügen und Verbessern verlagert. Aber dann ist es nicht mehr eine totale Kontrolle darüber.

Es ist bereits ein reines Wortspiel. Ihr Standpunkt wurde bereits früher klar umrissen: "Ich kann nicht kontrolliert werden", also ja, "vor irgendjemandem, irgendwo wird Drogen genommen, aber niemand steht mit einem Stock über mir und ich nehme keine Drogen".


Und Verbesserungen in Bezug auf die Bedienbarkeit der Sprache - in diesem Fall meine ich die Verfügbarkeit privater Konstruktoren von Objektmethoden nicht nur für den Fall der dynamischen Objekterzeugung - wird es bereits geben?

Und Sie machen gerne absichtliche Stolperfallen in Ihren "einfachen" Programmen: "Ich verstecke den Konstruktor in private, erstelle eine statische Methode und benutze sie dann, um in den versteckten Konstruktor zu meißeln"?


Ok, nehmen wir an, dass "C++ gefährlich und selbstmörderisch ist" und "MQL absolut sicher ist".

Warum sollte man eine Sprache, die so weit vom Kriterium der Sicherheit entfernt ist, als Grundlage für MQL nehmen, d. h. eine "absolut sichere" Sprache auf der Grundlage einer sehr "gefährlichen und selbstmörderischen" Sprache schaffen?

Sind Sie in der Lage, eine "andere Grundlage" für eine generische Sprache zu finden?

Damit jeder andere Programmierer die Sprache in die Hand bekommt und nach ein paar Stunden mit Freude darin schreiben kann und sie nicht angewidert und schimpfend wegwirft? Die Händler haben sich die Easy Language angeschaut und weggeworfen, während MQL4/MQL5 mit großer Freude verwendet und weiterentwickelt wird.

Die meisten gebräuchlichen Sprachen basieren auf den Grundprinzipien von Konstrukten wie in C/C++. Also nahmen wir das bekannte Framework, entfernten die gefährlichsten Dinge mit Links, fügten DRM hinzu und erhielten eine sichere und geschützte Sprache.

Das Ergebnis ist, dass wir auf dem Vormarsch sind und die Wettbewerber in die falsche, aber billigere Richtung gehen, wie sie meinen.

 
Renat:
Es bedeutet, dass jemand mehr Erfahrung darin hat, wissentlich die Freigabe mehrerer Softwareprodukte für einen konkurrierenden Markt zu leiten.

Übrigens, was die Erfahrung im Management betrifft. Vor 5 Jahren stritten wir im mql5-Forum über die Aussichten von MT5, ich sagte damals, dass die Zeit es zeigen wird. Fünf Jahre sind vergangen und wir sehen, dass die Gemeinschaft MT5 abgelehnt hat. Managementerfahrung ist keine Garantie gegen Fehler. Auch wenn man Erfahrung in einem Bereich hat, kann man Fehler machen. Zum Thema konkurrierender Markt bzw. Konkurrenten, ganz zum Schluss.

In diesem Fall handelt es sich jedoch nicht um eine Frage der Erfahrung mit vielen Softwareprodukten, sondern um die Qualität des Produkts und insbesondere des Compilers sowie der Werkzeuge und Methoden zur Erreichung einer hohen Qualität.

Renat:
Wir sollten die Diskussion nicht von den allgemeinen Grundsätzen der Qualitätskontrolle auf spezifische Mängel einer bestimmten Lösung verlagern. Das ist nicht möglich, weil man bei jedem Produkt jeden Fehler finden kann.


Dies ist nur eine Folge des Überschutzes "statische Klassenmethode hat kein Recht, in den Klasseninhalt einzudringen". Allerdings müssen wir in diesem Fall die Zugangskontrolle lockern.

Ich übersetze nicht, allgemeine Grundsätze, Theorie - nicht für die Theorie selbst, sondern für die Anwendung in der Praxis. Sie werden solche schwerwiegenden "Fehler" in denselben C/C++-Compilern nicht finden.

Wenn Sie sagen, dass in diesem Fall "eine statische Klassenmethode kein Recht hat, in den Inhalt der Klasse einzudringen", warum hat sie dann im Falle einer dynamischen Objekterzeugung bereits dieses Recht?

Was ist mit der Tatsache, dass sich eine nicht-statische Methode genau so verhält?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Dieselben Fehler:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

OK, denken wir an ein Verbot, "in den Inhalt der Klasse zu klettern":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

Das Objekt b wird durch den Aufruf des Kopierkonstruktors erzeugt, dann wird eine Zuweisung durch den Aufruf des "Operators =" durchgeführt, die Methode f() wird aufgerufen, und alle diese Konstruktoren, Operatoren und Methoden sind privat, was bedeutet, dass die statische Methode method() die Klasse "streicheln" darf:

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Betrachten wir ein weiteres Beispiel, das dem ersten sehr ähnlich ist:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Kompilierungsfehler, - sowohl Konstruktor als auch Destruktor sind nicht verfügbar:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Initialisieren Sie nun, ohne etwas zu ändern, die Variable a mit einem anderen Wert als dem Standardwert im Konstruktor:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Jetzt wird das Beispiel kompiliert und ausgeführt:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

Wie kommt es, dass eine statische Methode plötzlich "in den Inhalt der Klasse eindringen" darf?

Es ist ziemlich offensichtlich, dass es sich in diesem Fall nicht um einen "Überschutz", sondern um einen trivialen Fehler handelt. Totale Qualitätssicherung ist natürlich ein Schimpfwort, aber Fakten sind hartnäckige Dinge.

Renat:
Geben Sie ein funktionierendes Beispiel und nicht einen Fall von "Ich habe die Dinge absichtlich so verdreht, die Zugänge geschlossen und dann angefangen, mich auf das Verhalten an der Grenze zu berufen".

Bitte, ein klassisches Singleton, nämlich das Myers-Singleton, das im C++-Beispielteil des Links beschrieben ist:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

Mit der neu eröffneten Funktion lässt sie sich sogar in MQL4++ übersetzen:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Er kompiliert und wird ausgeführt:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Der Versuch, ein Objekt auf eine andere Weise als durch den Aufruf von OnlyOne::Instance() zu erstellen, führt zu einem Kompilierungsfehler.

Und zum Thema "Ich habe die Dinge absichtlich so verdreht, Zugänge verschlossen und dann angefangen, an das Grenzverhalten zu appellieren" - wurde etwas missbräuchlich verwendet?

Es gibt Mechanismen in der Sprache - ich habe das Recht, sie so zu verwenden, wie ich will, innerhalb der Grenzen, die die Sprache zulässt. Zumindest ist das bei C++-Compilern so.

Wenn es Fehler in der Sprachimplementierung gibt, ja, dann gibt es Fehler. Sie sprechen von einer totalen Qualitätskontrolle - also beseitigen Sie in der Praxis Implementierungsfehler im MQL4++-Compiler, so dass Fehler fast so schwer zu finden sind wie in C++-Compilern, da Sie eine solche Kontrolle haben. Ich glaube immer noch, dass der Parser nicht dazu beitragen wird, Fehler wie die von mir demonstrierten zu beseitigen.

Renat:
Und gefällt es Ihnen, in Ihre "einfachen" Programme absichtliche Schritte einzubauen: "Konstruktor in private verstecken, statische Methode erstellen und dann daraus den versteckten Konstruktor herausmeißeln"?

Es geht nicht darum, was ich mag oder nicht mag. Es gibt ein Werkzeug. Warum sollte ich mich weigern, alle seine Möglichkeiten zu nutzen?

In diesem Fall heißt es nicht einmal "Ich mag es". Es ist Myers, der es so sehr mag. Und irgendwie versucht niemand, ihn zu beschuldigen, er wolle den C++-Compilern "absichtlich ein Bein stellen".

Renat:
Sind Sie in der Lage, einen "anderen Rahmen" für generische Sprachen zu schaffen?

Damit jeder andere Programmierer eine Sprache in die Hand bekommt und nach ein paar Stunden mit Freude darin schreiben kann und sie nicht mit Abscheu und Schimpfworten wegwirft? Die Händler haben sich die Easy Language angeschaut und weggeworfen, während MQL4/MQL5 gerne verwendet und weiterentwickelt wird.

Die meisten verbreiteten Sprachen basieren auf den Grundprinzipien von Konstrukten wie in C/C++. Wir haben also einen vertrauten Rahmen genommen, die gefährlichsten Dinge mit Referenzen entfernt, DRM hinzugefügt und eine sichere Sprache geschaffen.

Das Ergebnis ist, dass wir an der Spitze stehen, während die Konkurrenten in die falsche Richtung gehen, aber billiger, wie sie meinen.

Das ist keine leichte Aufgabe und kann nicht auf Anhieb gelöst werden. Hier müssen Sie sich anstrengen, und zwar sehr anstrengen. Die große Mehrheit der MQL-Benutzer sind keine Programmierer. Dies muss bei der Sprachgestaltung berücksichtigt werden. Aber ich bin sicher, dass die Aufgabe gelöst werden kann.

Wenn überhaupt, würde es ausreichen, einige Strukturen zum alten MQL4 hinzuzufügen und einige Dinge wie Prioritäten zu Operationen zu bereinigen, wie es für MQL4++ gemacht wurde, und das wäre ein vernünftiger Kompromiss. Der Erfolg von MT4 war weitgehend auf die fehlende "Cleverness" der Sprache zurückzuführen. Dies ist jetzt nicht der Fall. Und es gibt viel mehr Fehler in der Compiler-Implementierung, denn MQL4++ ist viel komplizierter als das alte MQL4 und das Entwicklerteam hat sich kaum verändert.

Renat:
Das hat zur Folge, dass wir uns im Aufwind befinden, während unsere Konkurrenten in die falsche Richtung gehen, aber billiger, wie sie glauben.

In diesem Punkt stimme ich Ihnen zu, aber ich denke, das liegt vor allem daran, dass die Wettbewerber unverständliche Dinge tun.

 
Renat:
Das bedeutet, dass jemand wissentlich mehr Erfahrung in der Leitung der Freigabe vieler Softwareprodukte für den konkurrierenden Markt hat.


Wir müssen das Thema nicht von der Erörterung allgemeiner Qualitätskontrollprinzipien auf spezifische Mängel einer bestimmten Lösung verlagern. Eine solche Methode ist inakzeptabel, denn es ist immer möglich, in jedem Produkt einen Fehler zu finden.

Dies ist nur eine Folge des Überschutzes "eine statische Klassenmethode hat kein Recht, in den Inhalt der Klasse einzudringen". Allerdings müssen wir in diesem Fall die Zugangskontrolle lockern.

Geben Sie uns ein funktionierendes Beispiel, nicht einen Fall von "Ich habe alles absichtlich verdreht, die Zugänge gesperrt und dann angefangen, an das Grenzverhalten zu appellieren".


Die Probleme dort sind anderer Art. Und sie sind wissentlich um Größenordnungen größer, wenn man bedenkt, dass man keine statischen Analysatoren verwendet.


Das ist bereits ein reines Wortspiel. Ihre Position wurde bereits früher klar umrissen: "Ich kann nicht kontrolliert werden", also ja "vor jemandem, der irgendwo Drogen nimmt, aber niemand steht mit einem Stock über mir und ich nehme keine Drogen".


Möchten Sie in Ihre "einfachen" Programme bewusste Schritte einbauen: "Konstruktor in Private verstecken, statische Methode erstellen und dann daraus einen versteckten Konstruktor herausmeißeln"?


Sind Sie in der Lage, eine "andere Basis" für gemeinsame Sprachen zu finden?

Damit jeder andere Programmierer eine Sprache in die Hand bekommt und nach ein paar Stunden mit Freude darin schreiben kann und sie nicht angewidert und schimpfend wegwirft? Die Händler haben sich die Easy Language angeschaut und weggeworfen, während MQL4/MQL5 gerne verwendet und weiterentwickelt wird.

Die meisten verbreiteten Sprachen basieren auf den Grundprinzipien der Konstruktion wie in C/C++. Also nahmen wir das bekannte Framework, entfernten die gefährlichsten Dinge mit Links, fügten DRM hinzu und erhielten eine sichere und geschützte Sprache.

Das Ergebnis ist, dass wir an der Spitze stehen, während die Konkurrenten in die falsche Richtung gehen, aber billiger, wie sie meinen.

 

Hallo Forumsmitglieder!

Ich möchte die Anwesenheit von Renate in diesem Thema ausnutzen

Ich möchte einige Vorschläge zur Verbesserung von MT4 machen!

Jeder weiß, dass MT4 mit der Zeit immer schlechter funktioniert.

dann gehorcht sie der Maus nicht - finito!

Wir müssen auf einen neuen MT4 umsteigen und die

all das Zeug (Indikatoren, eXperts)!

Das ist eine Arbeit, die einen ganzen Tag dauert!

Obwohl es inzwischen Reparaturprogramme für DLL, Drever und andere gibt ...

Warum nicht einen Compiler für MT4 entwickeln?

Sie müssen 2 МТ4 haben (eine gültige und eine funktionierende)

und vergleichen sie regelmäßig und korrigieren Fehler im funktionierenden MT4.

Der zweite Vorschlag ist, nicht nur Preisdiagramme zu erstellen, sondern

produzieren Preis multipliziert mit Volumen Wachstumscharts!

Auf diese Weise können Sie sofort sehen, was vor sich geht (echter Handel oder Einlösung

stopes)

Ich denke, dass es für Menschen mit einem hohen Maß an Verständnis einfach ist!

Panza