Fehler, Irrtümer, Fragen - Seite 312

[Rashid Umarov]

Academic:

Diese Warnung sollte nicht ausgegeben werden, da die Funktion ObjectGetDouble einen Verweis übergibt und die if-Anweisung den von beiden Aufrufen zurückgegebenen Wahrheitswert prüft, und daher nur dann, wenn beide Funktionen wahr zurückgeben, diese Variablen behandelt werden, was bedeutet, dass beide Variablen nicht nicht auf den richtigen Wert gesetzt werden können.

Der Compiler macht sich nicht so viele Gedanken, um sicherzustellen, dass diese Variablen unbedingt als Ergebnis eines Aufrufs von ObjectGetDouble initialisiert werden. Versuchen Sie stattdessen, eine eigene Variable zu schreiben, in der der Wert für den per Referenz übergebenen Eingabeparameter explizit gesetzt wird. Was wird der Compiler sagen?

[Academic]

Rosh:
Der Compiler denkt nicht weit genug, um sicherzustellen, dass diese Variablen unbedingt als Ergebnis eines ObjectGetDouble-Aufrufs initialisiert werden. Versuchen Sie stattdessen, ein eigenes Programm zu schreiben, in dem der Wert für den Eingabeparameter, der als Referenz übergeben wird, explizit festgelegt wird. Was wird der Compiler sagen?

Rashid, es geht gar nicht um "Bewusstsein", sondern um Mathematik.

[Slava]

Academic:

Rashid, es geht gar nicht um "Bewusstsein", sondern um Mathematik.

1. Es gibt so etwas wie eine "verkürzte Auswertung logischer Ausdrücke".

2. Der Compiler kann nicht mit Sicherheit wissen, ob die per Verweis übergebene Variable gefüllt sein wird.

3. Eine Warnung ist genau das: eine Warnung, um Sie auf die Möglichkeit eines Problems aufmerksam zu machen.

[Rashid Umarov]

Academic:

Rashid, es geht gar nicht um "Bewusstsein", sondern um Mathematik.

Definieren wir eine solche Verschmelzung

bool AlwaysGood( double & param)
  {
   return true;
  }

Gibt es hier eine Garantie, dass die param-Variable initialisiert wird?

[Academic]

Rosh:

Ok, definieren wir eine solche fFunktion

Gibt es eine Garantie, dass die param-Variable initialisiert wird?

Dies ist eine Funktion, bei der das Ergebnis "param" NICHT verändert wird. Hier sollte die Warnung also zu 1000% ausgesprochen werden :)

Die Standardlösung ist hier folgende: Wenn es einen Codeausführungszweig gibt, bei dem der Wert nicht geändert werden kann, wird davon ausgegangen, dass diese Funktion den Wert nicht ändert. Und es wird eine Warnung ausgegeben.

Rashid, soll ich einen der modernen C++- und C-Compiler nehmen und einen solchen Code kompilieren, und ich bin sicher, dass keiner von ihnen eine Warnung für Linkshänder ausgeben wird.

Und wenn man solche "Probleme" mit der Erkennung solcher Dinge hat, kommen einem plötzlich starke Zweifel, dass es überhaupt keine Optimierung als solche gibt. Oder doch nicht?

[Slava]

Academic:

Rashid, wenn Sie wollen, dass ich irgendeinen der modernen C++- und C-Compiler nehme und ähnlichen Code kompiliere, bin ich mir sicher, dass keiner eine Warnung für Linkshänder aussprechen wird.

Worüber streiten wir uns? w0 setzen nicht

PS Es wird auf jeden Fall eine Nachricht geben (vielleicht ein paar Zeilen darunter)

[Slava]

Academic:

Das ist eindeutig keine Verbesserung, vor allem wenn es solche "Probleme" mit der Erkennung solcher Dinge gibt, dann schleicht sich der GROSSE Zweifel ein, dass es überhaupt keine Optimierung als solche gibt. Oder doch nicht?

Die Funktion ObjectGetDouble entzieht sich der Kontrolle des Compilers, da sie eine unabhängige (d. h. bibliothekarische) Implementierung hat

[Dmitriy Skub]

Academic:

Wenn Sie sich die Hilfe zu ObjectGetDouble:

---

Gibt je nach Erfolg der Funktion true oder false zurück. Bei Erfolg wird der Wert der Eigenschaft in der Zielvariablen abgelegt, die durch den letzten Parameter als Referenz übergeben wird.

---

Daraus lässt sich schließen, dass die Befüllung der Empfangsvariablen im Falle eines Fehlers nicht gewährleistet ist. Aus diesem Grund ist die Meldung des Compilers gültig.

IMHO.

[Sergey Chalyshev]

In der neuesten Version ist etwas nicht synchron.

Ich mache einen kleinen EA:

int OnInit()
  {
   Print("Все нормально!"); 
   return(0);
  }

Ausführen des Testers,

2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Alles in Ordnung!

Ich nehme Änderungen an meinem EA vor:

int OnInit()
  {
   Print("Тестер, Аууу, ты где?"); 
   return(0);
  }

Ich kompiliere es, führe den Tester aus, und er antwortet:

2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 Alles normal!

Es hilft nur, das Terminal neu zu starten.

[Slava]

Serj_Che:

In der neuesten Version ist etwas nicht synchron.

Ich mache einen kleinen EA:

Ausführen des Testers,

2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Alles in Ordnung!

Ich nehme Änderungen an meinem EA vor:

Ich kompiliere es, führe den Tester aus, und er antwortet:

2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 Alles normal!

Es hilft nur, das Terminal neu zu starten.

Entschuldigung. Heute oder morgen wird ein neuer Build ohne diesen unglücklichen Fehler veröffentlicht werden.