Fehler, Irrtümer, Fragen - Seite 2116

[A100]

Die Funktionsargumente werden nicht von rechts nach links berechnet

int i = 0;
int _etLastError() { return i; }
int _tringGetCharacter( string, int ) { i = 5041; return 0; }
void OnStart()
{
    string abc = "ABC";
    ResetLastError();
    Print( ::StringGetCharacter( abc, 1024 ), ":", GetLastError()); //(*)слева направо
    Print(   _tringGetCharacter( abc, 1024 ), ":", _etLastError()); //   справа налево
}

String Ergebnis (*) : 0:5041

In beiden Fällen wird dies erwartet: 0:0

[Koldun Zloy]

A100:

Die Funktionsargumente werden nicht von rechts nach links berechnet

String Ergebnis (*) : 0:5041

Dies war in beiden Fällen zu erwarten: 0:0

Dies ist kein Fehler. Der Compiler entscheidet selbst, in welcher Reihenfolge er die Argumente berechnet.

Das muss man einfach berücksichtigen.

[A100]

Koldun Zloy:

Dies ist kein Fehler. Der Compiler entscheidet selbst, in welcher Reihenfolge die Argumente zu berechnen sind.

Der Fehler ist folgender: Bis vor kurzem war die Reihenfolge durch https://www.mql5.com/ru/forum/1111/page2040#comment_5858419 streng definiert (man beachte das Datum und den Auszug aus der Dokumentation: garantiert). Dann wurde die Reihenfolge still und leise geändert (auch in der Dokumentation), und sie konnte auf zivilisierte Weise geändert werden - über inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Aber wie soll der Nutzer davon erfahren? Soll der Benutzer es erraten? Oder sehen Sie sich die Dokumentation an, bevor Sie ein Tool verwenden?

[A100]

Kompilierungsfehler und mehr

#define MACRO( X )      #X
void OnStart()
{
        Print( MACRO( AC/DC    )); //нормально
        Print( MACRO( AC\\DC   )); //error: '\' - illegal escape sequence
        Print( MACRO( ABC\nDEF )); //error: '\' - illegal escape sequence
        Print( MACRO( 'ABC'    )); //error: '' - single quote needed
        Print( MACRO( "ABC     )); //error: '' - double quotes are needed
        Print( MACRO( "ABC"    )); //Результат: ABC вместо "ABC"
        Print( MACRO( '"'ABC   )); //нормально
}

[Koldun Zloy]

A100:

Der Fehler ist folgender: Bis vor kurzem war die Reihenfolge durch https://www.mql5.com/ru/forum/1111/page2040#comment_5858419 streng definiert (man beachte das Datum und den Auszug aus der Dokumentation: garantiert). Dann wurde die Reihenfolge still und leise geändert (auch in der Dokumentation), und es war möglich, sie auf zivilisierte Weise zu ändern - über inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Aber wie soll der Nutzer davon erfahren? Soll der Benutzer es erraten? Oder die Dokumentation durchlesen, bevor Sie ein Tool benutzen?

Sie müssen nur keinen Code schreiben, der von der Reihenfolge der Berechnung der Argumente abhängt.

In C++ hat der Compiler das Recht, eine Funktion einzubinden, auch wenn sie nicht das Schlüsselwort inline hat.

In MQL gibt es kein Inline-Schlüsselwort, der Compiler bindet Funktionen nur nach eigenem Ermessen ein.

Die Reihenfolge der Berechnungen von rechts nach links ist offensichtlich darauf zurückzuführen, dass die Argumente in dieser Reihenfolge auf dem Stapel abgelegt werden,

aber sie können auch durch Register geleitet werden.

Und bei eingebauten Funktionen gibt es überhaupt keine Übergabe von Argumenten als solche.

[A100]

Koldun Zloy:

1. Sie brauchen nur keinen Code zu schreiben, der von der Reihenfolge abhängt, in der die Argumente berechnet werden.

2. In C++ hat der Compiler das Recht, eine Funktion zu inlinen, auch wenn sie nicht das Schlüsselwort inline enthält.

3. In MQL gibt es kein Inline-Schlüsselwort, der Compiler bettet nur Funktionen nach eigenem Ermessen ein.

4. Die Reihenfolge der Berechnungen von rechts nach links scheint mit der Tatsache zusammenzuhängen, dass die Argumente in dieser Reihenfolge auf den Stapel gelegt werden,

aber sie können auch über Register weitergegeben werden.

5. Und bei eingebauten Funktionen gibt es überhaupt keine Argumentübergabe.

1. Warum sollte das nicht so sein, wenn die umgekehrte Reihenfolge in der Dokumentation garantiert ist und der Code in diesem Fall einfacher und klarer ist? Wir könnten genauso gut die Verwendung von 5 + (2*3) als Operationspriorität ablehnen und verlangen, dass überall Klammern (5 + (2*3)) gesetzt werden - für den Fall, dass sie plötzlich geändert wird

2. Der C++-Compiler stellt bestimmte Anforderungen an die eingebetteten Funktionen, so dass eine solche Situation ausgeschlossen ist https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.

3. So sollte sie eingeführt werden

4. In Registern (im Gegensatz zum Stack) können Argumente in beliebiger Reihenfolge platziert werden, auch in umgekehrter Reihenfolge

5. Es geht nicht um die Reihenfolge der Übergabe, sondern um die Reihenfolge der Berechnung der Argumente, und das ist die Reihenfolge jeder Funktion mit mehr als einem Argument. Und C++ berücksichtigt dies, bevor es eine Funktion inline macht (oder nicht macht) (siehe Punkt 2)

[Koldun Zloy]

A100:

1. Warum nicht, wenn die umgekehrte Reihenfolge in der Dokumentation garantiert ist und der Code einfacher und übersichtlicher ist. Wir könnten genauso gut die Verwendung von 5 + (2*3 ) verweigern und fordern, überall Klammern (5 + (2*3)) zu setzen - für den Fall, dass sie plötzlich geändert wird

2. Der C++-Compiler stellt bestimmte Anforderungen an die eingebetteten Funktionen, so dass eine solche Situation ausgeschlossen ist https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.

3. So sollte sie eingeführt werden

4. In Registern (im Gegensatz zum Stack) können Argumente in beliebiger Reihenfolge platziert werden, auch in umgekehrter Reihenfolge

5. Es kommt nicht auf die Reihenfolge der Übergabe an, sondern auf die Reihenfolge der Berechnung der Argumente, und das ist bei jeder Funktion mit mehr als einem Argument der Fall. Und C++ berücksichtigt dies, bevor es eine Funktion inline macht (oder nicht macht) (siehe Punkt 2)

3. ich weiß nicht, was Ihnen das bringt. Wollen Sie dem Compiler verbieten, Funktionen einzubetten, ohne sie explizit als inline zu kennzeichnen?

2. Ich weiß nicht, was Sie meinen.

4. Ich habe nur angedeutet, worauf sich dieser Auftrag und seine Annullierung beziehen. Ich glaube nicht, dass dies ein Zufall war, und das wird auch in Zukunft so sein. Daran ist nichts Schlimmes.

5. Sie irren sich. In C++ ist die Reihenfolge der Berechnung von Argumenten nicht festgelegt.

1. Ich schreibe schon seit vielen Jahren in C++ und habe dies nie als Problem empfunden.

[A100]

Koldun Zloy:

3. ich weiß nicht, was das für Sie bedeuten wird. Möchten Sie den Compiler daran hindern, Funktionen einzubetten, ohne sie explizit als inline anzugeben?

4. Ich habe lediglich angedeutet, worum es bei dieser Bestellung und ihrer Annullierung ging. Ich glaube nicht, dass dies zufällig geschah, und es wird immer so sein. Es ist nichts Schreckliches dabei.

5. Sie irren sich. In C++ ist die Reihenfolge der Berechnung von Argumenten nicht definiert.

3. ich habe vorgeschlagen, dass es dem Compiler nicht erlaubt sein sollte, die Reihenfolge der Berechnung von Argumenten für Funktionen ohne Inlines zu ändern.

5. Die Reihenfolge der Berechnung wird von der Implementierung (dem Compiler) festgelegt und ist recht konkret (entweder von rechts nach links oder von links nach rechts), wie zum Beispiel hier:

void OnStart()
{
    ResetLastError();
    Print( GetLastError(), ":", StringGetCharacter( "abc", 1024 ), ":", GetLastError());
}

es ist nicht klar, welche Reihenfolge 2-1-3 oder 2-3-1 oder was auch immer ist.

Ergebnis: 5041:0:5041.

Erwartet: 0:0:5041 von links nach rechts oder

5041:0:0 von rechts nach links

[fxsaber]

A100:

es ist nicht klar, welche Reihenfolge 2-1-3 oder 2-3-1 oder was auch immer ist

Ich verstehe nicht, warum man einen Code schreibt, der offensichtlich zweideutig ist?

[A100]

fxsaber:

Ich verstehe nicht, warum man einen Code schreibt, der offensichtlich zweideutig ist?

Eine ähnliche Frage an Sie https://www.mql5.com/ru/forum/1111/page2037#comment_5842347