Warum funktioniert ein leerer Type-Conversion-Operator ?

happystudent

Arcoth schrieb:

Der Compiler muss die Information, dass eines dieser "Events" auftreten muss, nicht nutzen, geschweige denn überprüfen.

Aber der Compiler darf doch nur bei solchen Schleifen annehmen dass sie terminieren, die keine der oben genannten Dinge machen. Also muss er das doch überprüfen?

Wenn ich schließlich etwas habe wie:

for (;;)
{
    do_something();
}

dann ist das wenn do_something z.B. in eine Datei schreibt doch nicht UB (trotz endlos-Laufzeit) und der Compiler kann die Schleife nicht einfach zusammen-optimieren. Also muss er doch erstmal untersuchen ob do_something etwas macht dass die Schleife "legal-endlos" macht oder nicht?

hustbaer

Der Compiler muss bei allem was er nicht "einsehen" kann annehmen, dass es alles macht was es machen kann.
Er muss immer "pessimistisch" optimieren.

Wobei man dem Compiler natürlich Listen spendieren könnte, bzw. z.B. die Standard Header Files (des Compilers, des OS', ...) mit diversen non-Standard Pragmas/Attributen/... versehen, die die nötigen Informationen enthalten.

Wie weit das bereits üblich ist oder nicht kann ich nicht sagen. Beim Windows SDK sind mir bisher auf jeden Fall keine solchen Attribute/... aufgefallen.

Interessant wären da ja z.B. auch andere Dinge. Wie z.B. ob eine Funktion einen übergebenen Wert "nur verwendet", oder ob sie ihn u.U. irgendwo in eine Datenstruktur reinschreibt, wo ihn andere Funktionen "aufgreifen" könnten.

Nochmal konkret zu deinem Beispiel: wenn der Compiler den Code von do_something "sehen" kann (inklusive aller aufgerufenen Unterfunktionen und deren Unterfunktionen), und darin keine Beobachtbaren Effekte zu finden sind, dann kann er die Schleife wegoptimieren. Anderenfalls kann er das nicht.