Fehler, Irrtümer, Fragen - Seite 493
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich widerspreche nicht.
aber auf diese Weise
Es gibt sowieso eine Rundung, sollte sie das tun?
Die Entwickler.
Ich habe versehentlich die Verarbeitung von Ticks in Expert Advisor in einer Schleife durchgeführt, woraufhin eine kritische Fehlermeldung über einen Stapelüberlauf erschien.
Das Problem ist, dass die Nachricht keine spezifischen Informationen darüber enthält, was und wo genau es passiert ist.
Ich schlage vor, den Text dieser Nachricht zu verdeutlichen, wenn es möglich ist, solche Probleme (wie der Aufruf einer Klassenmethode aus einer aufgerufenen Methode) in der Kompilierungsphase abzufangen.
Der Grund, warum iCustom() diesen Pufferzellen, die in Wirklichkeit mit nichts gefüllt waren, beliebige Werte zuweist, ist mir unklar, ebenso wie der Grund, warum dies in keiner Weise vermieden werden kann.
Ich vermute, es hat etwas mit der Zuweisung von Speicher für das entsprechende Datenfeld des Indikatorpuffers zu tun.
Eine solche Operation von iCustom(), bei der es unmöglich ist, die Herkunft und den Wahrheitsgehalt der Daten festzustellen, erscheint mir unzulässig und schafft zusätzliche Risiken für den Nutzer.
Wenn iCustom() den Pufferzellen willkürliche, nicht mit den realen Werten übereinstimmende Werte zuweist,
Warum wird diesen Zellen nicht der Wert "Empty_Value" zugewiesen, wie es in MT4 implementiert ist?
Dann wäre zumindest ihr Status klar.
Die Entwickler.
..........., wenn möglich, solche Probleme (z.B. Aufruf einer Klassenmethode aus einer aufgerufenen Methode) zur Kompilierzeit abfangen wollen.
Ich bin dagegen. Dies würde den Compiler übermäßig kompliziert und daher weniger zuverlässig machen.
Es obliegt dem Programmierer, falsche Rekursionen zu verfolgen.
Ich möchte aber, dass die Fehlermeldung den Namen der Funktion enthält, die den Stapel zum Überlaufen gebracht hat.
Niemand außer dem Autor kann entscheiden, womit ungenutzte Pufferwerte gefüllt werden sollen. Sie sagen Empty_Value, aber ich möchte zum Beispiel, dass es 0 oder etwas anderes ist. Welchen Wert Sie auch immer wünschen, initialisieren Sie ihn damit.
Das ist richtig und logisch. Das Problem ist jedoch, dass die Funktion iCustom() Pufferzellen, die der Benutzer nicht mit irgendetwas (!) gefüllt hat, periodisch nach eigenem Ermessen mit beliebigem Müll füllt. Soll das so sein?
Ich bin dagegen. Es würde den Compiler exorbitant komplex und damit weniger zuverlässig machen.
Es ist Sache des Programmierers, eine falsche Rekursion zu verfolgen.
Ich möchte jedoch, dass die Fehlermeldung den Namen der Funktion enthält, die den Stapel zum Überlaufen gebracht hat.
Ja, wir verkomplizieren die Arbeitsmaschine (immerhin handelt es sich um ein natives 32/64-System) absichtlich nicht mit Metainformationen.
Rekursion ist in der Regel leicht zu erkennen - sie hängt direkt von der Größe der lokalen Variablen ab, und es gibt nur sehr wenige solcher Stellen in einem Programm.
Das ist richtig und logisch. Aber das Problem ist, dass die Pufferzellen, die der Benutzer nicht gefüllt hat (!), iCustom()-Funktion füllt nach eigenem Ermessen mit zufälligen Müll. Ist es soll so sein?
Wenn der benutzerdefinierte Indikator seinen Puffer nicht korrekt füllt, ist dieser benutzerdefinierte Indikator schuldig.
Und wenn dieser benutzerdefinierte Indikator seine Ergebnisse über iCustom sendet, ist er doppelt schuldig, da er die Benutzer in die Irre führt.
Wenn ein benutzerdefinierter Indikator seinen Puffer nicht korrekt füllt, bedeutet dies, dass dieser benutzerdefinierte Indikator schuldig ist.
Und wenn dieser benutzerdefinierte Indikator seine Ergebnisse über iCustom ausgibt, ist er doppelt schuldig, da er die Benutzer in die Irre führt.
Wenn ein benutzerdefinierter Indikator seinen Puffer nicht richtig füllt, ist dieser benutzerdefinierte Indikator daran schuld.
Und wenn dieser benutzerdefinierte Indikator seine Ergebnisse über iCustom sendet, ist er doppelt schuldig, weil er die Benutzer in die Irre führt.
Ich verstehe immer noch nicht, was Sie daran hindert, das Programm nicht nur effizient, sondern auch bequem zu gestalten? Wenn ich mich richtig erinnere, ist der Grund für das Fehlen einer eingebauten Initialisierung von Indikatorpuffern in 5 die Optimierung der Geschwindigkeit. In diesem Fall muss der Indikatorentwickler die Initialisierungszeichenfolgen ("Nullen") selbst kodieren, was bisher bei vier Systemen vom Kernel durchgeführt wurde. Die daraus resultierende Effizienz scheint also nicht besser zu werden, und die Benutzerfreundlichkeit leidet. Aber da man sich aus irgendeinem Grund für diesen Weg entschieden hat, warum sollte man ihn nicht fakultativ machen? D.h. wir könnten eine weitere #Eigenschaft einführen, die angibt, ob die Puffer automatisch initialisiert werden sollen oder nicht.
Zusammenfassend wiederhole ich den Gedanken, den ich schon einmal geäußert habe: Die Aufgabe der Plattform, die MT ist, besteht darin, den Benutzer (den Programmierer) so weit wie möglich vor möglichen "Fehlern" zu schützen.
Das ist richtig und logisch. Aber das Problem ist, dass Pufferzellen, die der Benutzer nicht (!) mit irgendetwas gefüllt hat, von iCustom() regelmäßig nach eigenem Ermessen mit beliebigem Müll gefüllt werden. Soll das so sein?
Eigentlich ist es eine allgemeine Regel: Die Initialisierung von Arrays liegt im Ermessen des Benutzers. Ein nicht initialisiertes Array enthält zufällige Werte aus dem ihm zugewiesenen Speicher. Der Benutzer kann einen guten Grund haben, das Array nicht unnötig zu initialisieren (z.B. um Zeit zu sparen). Auf diese Weise spare ich manchmal Zeit, wenn ich sicher bin, dass ich den Müll nicht lesen und "fressen" muss, bevor die eigentlichen Informationen da sind.
Ich sehe keine Böswilligkeit auf Seiten von MQ. Ich hätte eher etwas dagegen, wenn sie "prophylaktisch" meine Programme verlangsamen würden.