Fehler, Irrtümer, Fragen - Seite 2532

Neuer Kommentar
 
Igor Makanu:

alles funktioniert, aber Arrays, die Indikatorpuffer sein werden, sollten mit dem Modifikator public beschrieben werden

Ja, natürlich.

Natürlich ist der öffentliche Zugriff auf die Klassenmitglieder nicht gut, aber das Hauptproblem - der Zugriff auf die Array-Daten ohne Kopieren - ist gelöst.

Danke, die Frage ist geklärt.

 
Wenn die Frage geklärt ist, können Sie mir helfen? Für euch Mammuts der Programmierung ist es wie ein Schilfrohr...
 
Georgiy Merts:

Natürlich ist der öffentliche Zugriff auf Klassenmitglieder nicht gut, aber das Hauptproblem - der Zugriff auf Array-Daten ohne Kopieren - ist gelöst.

Ich schaue mir viele Videos auf YouTube an, ich bin auf den Kanal eines intelligenten Programmierers gestoßen, und ich erinnere mich an den Satz: "Der Code muss in erster Linie seine Aufgabe erfüllen!

Sie arbeiten nicht an einem großen Projekt, oder? - Sie wissen, warum dieses Klassenmitglied definiert ist und Sie können den Zugriff darauf ohne die Hilfe des Compilers kontrollieren, oder? ;)

 

@Ilyas, aktualisierte Version von mt4


Code, der nach dem Kompilieren und Ausführen von Fehlern problemlos funktionierte


 
Igor Makanu:

Ich schaue mir viele Videos auf YouTube an, ich bin auf den Kanal eines guten Programmierers gestoßen, und ich erinnere mich an den Satz: "Der Code muss in erster Linie seine Aufgabe erfüllen!

Sie arbeiten nicht an einem großen Projekt, oder? - Sie wissen, warum dieses Klassenmitglied definiert ist und Sie können den Zugriff darauf ohne die Hilfe des Compilers kontrollieren, oder? ;)

Eigentlich ist es besser, den Zugriff auf Klassenmitglieder durch Methoden zu implementieren, und um weniger Dereferenzierungen zur Laufzeit zu haben, verwenden Sie Inline mit Get-Methoden.
 
Igor Makanu:

Ich schaue mir viele Videos auf YouTube an, ich bin auf den Kanal eines guten Programmierers gestoßen, und ich erinnere mich an den Satz: "Code muss in erster Linie seine Aufgabe erfüllen! ....

Sie arbeiten nicht an einem großen Projekt, oder? - Sie wissen, warum dieses Klassenmitglied definiert ist und Sie können den Zugriff darauf ohne die Hilfe des Compilers kontrollieren, oder? ;)

NEIN.

Zunächst einmal muss der Code transparent und verständlich und leicht zu pflegen sein. Und wenn es dann seine Aufgabe nicht erfüllt, werden Sie es sofort sehen.

Wenn der Code jedoch aus vielen Fragmenten mit potenziell unsicheren Konstrukten besteht, die sehr subtile, nicht offensichtliche Fehler verursachen, kann man nie sicher sein, dass "der Code seine Aufgabe erfüllt".

Und wenn man an einem großen Projekt arbeitet, kann man gar nicht ohne sie auskommen, denn in vielen Unternehmen gibt es offizielle Richtlinien für die Notation, die Deklaration, was als Aktien deklariert werden kann und was nicht und so weiter. Wenn Sie alleine arbeiten, deklarieren Sie natürlich ein Klassenmitglied, Sie wissen, wofür es ist und wie Sie es verwenden werden. Allerdings neigt jeder noch so komplexe Code, selbst wenn er von einem Programmierer erstellt wird, dazu, die Architektur zu verändern. Und ich persönlich kann mich nicht daran erinnern, was, wo, wie und wozu. Gleichzeitig habe ich den Code großzügig mit ausführlichen Kommentaren überladen. Und dennoch, wenn ich nach einem halben Jahr auf andere Fragmente zurückkomme, verbringe ich viel Zeit damit, zu verstehen, warum es so und nicht anders gemacht wurde. Ohne Kommentare wäre ich nicht in der Lage, meinen eigenen Code überhaupt zu verstehen.

Wenn Sie über das Gedächtnis von Peter Konov verfügen, müssen Sie sich natürlich keine Gedanken über den gemeinsamen Zugriff machen, machen Sie alle Variablen global - und verwenden Sie alles, was Sie brauchen, wann immer Sie wollen. Allerdings ist mein Gedächtnis viel schlechter, und ich kann schon nach einer Woche die Feinheiten eines Verfahrens vergessen. Deshalb habe ich schon vor langer Zeit den Grundsatz entwickelt, dass an jeder Stelle des Codes genau so viel vorhanden sein muss, wie ich hier brauche, und keine einzige Variable mehr. Am besten ist es, alles in virtuelle Schnittstellen umzuwandeln und die Verantwortungsbereiche der einzelnen Klassen so weit wie möglich aufzuteilen (aber natürlich muss es ein gewisses Maß geben, damit man sich nicht mehr mit diesen Wrappern als mit nützlichem Code beschäftigt).

Erinnern Sie sich daran, dass das Fehlen von Zeigern auf Arrays von den Entwicklern damit begründet wird, dass sie sich um die Programmierer kümmern", damit Sie nicht versehentlich einen Zeiger auf ein Array verwenden, das nicht mehr relevant ist. Für Klassen ist das jedoch kein Problem. Nun, sie erklärten, dass "wenn Sie mit Klassen schreiben, sind Sie bereits erfahren genug, um Zeiger zu verwenden, während Arrays für Anfänger verfügbar sind, und wir wollen nicht, dass sie Probleme haben, wenn sie Zeiger auf Arrays verwenden wollen... keine Hinweise, das war's"...

 
Vladimir Simakov:
Im Allgemeinen ist es besser, den Zugriff auf Klassenmitglieder über Methoden zu implementieren, und um eine Dereferenzierung zur Laufzeit zu vermeiden, verwenden Sie Inline-Methoden mit get.

Das stimmt. Und ich bin normalerweise dazu geneigt. Im Allgemeinen verwende ich nur selten öffentliche Klassenmitglieder, alle Zugriffe erfolgen über Inline-Methoden. Nur in besonderen Fällen, wie bei diesen Indikator-Arrays, muss ich öffentliche...

 
Влад:
Wenn das Problem gelöst ist, können Sie mir dann weiterhelfen? Für euch Mammuts der Programmierung ist es wie eine Motte...

In Ihrem Fall sollten Sie eher eine while()-Schleife als eine for()-Schleife organisieren.

Prüfen Sie, ob es ein Anzeichen für das Ende des Blinkens gibt.

Aber das mit dem "Blinken mit variabler Frequenz" ist etwas seltsam... Ich sehe keine Fehler, es sollte ziemlich oft blinken.

Obwohl ich bezweifle, dass es sinnvoll ist, grafische Objekte zu erstellen und zu löschen, anstatt sie unsichtbar zu machen. Aber es scheint, dass man ein Objekt nicht unsichtbar machen kann... Es bleibt also nur noch das Löschen übrig.

 
Georgiy Merts:

Wenn Sie über ein Gedächtnis wie das von Peter Konov verfügen, brauchen Sie sich natürlich keine Gedanken über die Zugriffstrennung zu machen, machen Sie alle Variablen global - und verwenden Sie alles, was Sie brauchen, wann immer Sie wollen.

Ich trainiere nie den Speicher, verwende globale Variablen nur als letzten Ausweg, der Code erscheint mir manchmal sogar redundant, aber Codefragmente sind auf ein anderes Projekt übertragbar,

Normalerweise verwende ich lange Funktions- und Variablennamen, damit ich lesen kann, was ich vorher geschrieben habe:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
Ein weiteres Problem ist, dass ich mich nicht an den OOP-Stil halte - ich verpacke nicht alles in Klassen, ich verwende sowohl den prozeduralen als auch den OOP-Stil gleichzeitig in einem Programm, es ist bequemer und schneller, ein Programm aus vorgefertigten Blöcken zu erstellen, was auch immer fehlt, ich füge es hinzu oder ändere es entsprechend der Aufgabe
 
Vladimir Simakov:
und für weniger Dereferenzierung zur Laufzeit, verwenden Sie Inline mit Get-Methoden.
Inline ist meiner Meinung nach ein Relikt. Der Compiler inlinert alles perfekt, so dass es keinen Grund gibt, den Code zu überladen. Und in MQL ist dieser Spezifizierer gar nichts, nur aus Kompatibilitätsgründen hinzugefügt (ich weiß nicht, wozu, wenn man ein solches Makro selbst deklarieren könnte).
1...252525262527252825292530253125322533253425352536253725382539...3184
Neuer Kommentar