kurze Frage:
Ich möchte das eine Operation garantiert durchgeführt wird, wenn eine Funktion verlassen wird, egal ob durch return oder exception.

Also habe ich mich an RAII erinnert und diese Operation in den Destruktor einer Klasse gepackt, und von dieser Klasse erstelle ich eine Instanz auf dem Stack wenn ich die Funktion betrete. Dadurch ist ja garantiert, dass durch Stackunwinding die Instanz zerstört wird, wenn der Scope der Funktion verlassen wird.

Allerdings graut mir meine IDE dieses lokale Objekt aus, weil es nie benutzt wird. Könnte es vom Compiler wegoptimiert werden, so dass meine wichtige Funktion vielleicht garnicht ausgeführt wird?

class EnsureOperation{
    ~EnsureOperation() { wichtige_funktion_ausfuehren();}
};

double foo() throw(Exception) {
    EnsureOperation eo;
    // mach was
    return bla;
}

Ist sicher, dass bei verlassen von foo die wichtige_funktion ausgeführt wird?

Gruß,
Phil

Was passiert denn, wenn du da anstatt der Funktion ne Ausgabe machst? (und wirds auch ausgegraut? Und was passiert, wenn du wirklich nix drin hast?)

Falls du eine Warning oder so bekommst, könntest du ja auch einfach noch ein

eo;

anfügen. Das sollte dann zumindest das ausgrauen und die mögliche Warning aushebeln.

btw:
Ich bezweifle, dass da überhaupt ein Funktionsaufruf wegoptimiert wird, welcher nicht inline ist. (kann mich irren, aber ich denke das ist sehr schwer (auch für moderne Compiler) ohne den Code der Funktion zu kennen).

Die Funktion ändert openAL contexte. Das fällt wohl unter Seiteneffekte, oder?

Ja. Hier handelt es sich wohl um einen Bug.
Stell das Feature in deiner IDE einfach ab. Ist sowieso sinnfrei, denn wenn du wirklich mal ein unbenutztes Objekt irgendwo hast, dann wird dich der Compiler schon warnen. Und das deutlich zuverlässiger.

Ja. Hier handelt es sich wohl um einen Bug.
Stell das Feature in deiner IDE einfach ab. Ist sowieso sinnfrei, denn wenn du wirklich mal ein unbenutztes Objekt irgendwo hast, dann wird dich der Compiler schon warnen. Und das deutlich zuverlässiger.

Klingt vernünftig. Hätte mich aber auch schwer gewundert, wenn man einen Funktionsaufruf so einfach komplett wegoptimieren könnte.

Danke!

PhilippM schrieb:

Die Funktion ändert openAL contexte. Das fällt wohl unter Seiteneffekte, oder?

Ja. Hier handelt es sich wohl um einen Bug.
Stell das Feature in deiner IDE einfach ab. Ist sowieso sinnfrei, denn wenn du wirklich mal ein unbenutztes Objekt irgendwo hast, dann wird dich der Compiler schon warnen. Und das deutlich zuverlässiger.

Wieso ein Bug? Ich finde dass so eine Funktion nicht schlecht ist, ich würde das an lassen.

Leitet Deine Klasse vielleicht von einer anderen ab was Du im Minimalbeispiel weggelassen hast?

Wieso sollte das eine Rolle spielen?

drakon schrieb:

Falls du eine Warning oder so bekommst, könntest du ja auch einfach noch ein

eo;

anfügen.

Das funktioniert leider nicht auf allen Compilern. Eine längliche Diskussion zum Thema gibts in Sutter's Mill.

So eine Funktion kann wohl schwer unterscheiden, ob die Seiteneffekte des ctor/dtor "nötig" sind, und der einzige Grund warum das Objekt dortsteht, oder ob der Programmierer es einfach nur übersehen hat.
Beispiel: ich kann einen ofstream "vergessen" zu entfernen, der nichtmehr verwendet wird. Ich kann den ofstream aber genauso verwenden, um einfach nur ein leeres File anzulegen.

Ich verstehe das Problem nicht.
Es compiliert doch alles gut, verhält sich richtig etc.

Das es sich richtig verhält hat der TO nicht gesagt.
Ich habe das so verstanden, dass er nicht weiss, ob die Funktion ausgeführt wird oder nicht und er war einfach nur von der IDE iritiert, die ihm sagt, dass das Objekt nicht gebraucht wird. Und ich kenne den iritierenden Effekt von falschen IDE Einfärbunge o.ä. sehr gut und verstehe, dass er nachfrägt.

Und da

1. er nicht gesagt hat dass es sich falsch verhält,
2. es sich nach dem Standard so verhalten muss wie er es erwartet und
3. ich auch noch nie einem Compiler begegnet wäre wo es sich nicht korrekt verhalten würde
   gehe ich davon aus dass auch alles so funktioniert wie es sollte.

Es _scheint_ sich alles richtig zu verhalten...

Aber bei C++ weiß man ja nie, ob es sich nur "zufällig richtig verhält" oder es tatsächlich richtig so ist. Daher die Nachfrage.

Aber bei C++ weiß man ja nie, ob es sich nur "zufällig richtig verhält" oder es tatsächlich richtig so ist. Daher die Nachfrage.

Aber bei C++ weiß man ja nie, ob es sich nur "zufällig richtig verhält" oder es tatsächlich richtig so ist. Daher die Nachfrage.

Wie sich C++ verhält steht im Standard - nur ob sich die Compiler so verhalten ist die Frage. Vor allem wenn man die aus MS-Office bekannte Verhaltensweise "Ich tu alles von dem ich glaube dass du es gemacht haben willst auch wenn ich das garnicht wissen kann und dir damit tierisch auf die Nerven gehe" kennt, ist die Frage für MSVC durchaus berechtigt gewesen

PhilippM schrieb:

Aber bei C++ weiß man ja nie, ob es sich nur "zufällig richtig verhält" oder es tatsächlich richtig so ist. Daher die Nachfrage.

Wie sich C++ verhält steht im Standard - nur ob sich die Compiler so verhalten ist die Frage.

Na hoffentlich halten die sich nicht so genau an den Standard http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html

Sie ist aber nicht falsch, die Einfärbung. Sie zeigt an, dass da was instanziert wird, was dann nirgends referenziert wird.

Ja sie ist in dem Sinne schon korrekt, aber iritierend.

Und da

1. er nicht gesagt hat dass es sich falsch verhält,
2. es sich nach dem Standard so verhalten muss wie er es erwartet und
3. ich auch noch nie einem Compiler begegnet wäre wo es sich nicht korrekt verhalten würde
   gehe ich davon aus dass auch alles so funktioniert wie es sollte.

1. Weil er es ja offensichtilch schlichtweg nicht weiss. (er weiss anscheinend nicht, wie er das rausfinden soll)
2. Wenn sich der Compiler dran hält ja.
3. Was ja trotzdem die Frage erlaubt

Wie gesagt ich finde die Frage berechtigt, wenn man nicht weiss unter welchen Umständen ein Compiler sowas wegoptimieren darf und es nicht kontrollieren kann. (da dürfte sich, denke ich etwas mit einem externen Logger oder so machen lassen)

Das es so funktionieren sollte sind wir uns, denke ich einig. Falls es wegoptimiert werden würde, verhält sich der Compiler wohl falsch.

Ich könnte mir aber durchaus gut vorstellen, dass, wenn der Funktionsaufruf geinlinet wird und der Compiler sieht, dass da nix drin gemacht wird, er dann da wirklich das ganze Objekt wegoptimiert.

@pumuckl:
Zum Glück scheinen die VS-Entwickler einiges mehr Wert auf konsistenz und klares Verhalten zu legen, als die Office, oder gar IE-Entwickler.

Ich könnte mir aber durchaus gut vorstellen, dass, wenn der Funktionsaufruf geinlinet wird und der Compiler sieht, dass da nix drin gemacht wird, er dann da wirklich das ganze Objekt wegoptimiert.

Solange die "as if" Regel nicht verletzt wird, das compilierte Programm also die gleichen beobachtbaren Effekte hat wie sie der Standard für den entsprechenden Source-Code vorschreibt, sind solche Optimierungen erlaubt.

Allerdings total harmlos, da die wegoptimierten Teile dann ja keine beobachtbaren Effekte haben können.

Sowas kann nur doof werden im Zusammenhand mit Multi-Threading (aber auch nur dann, wenn man als Programmierer irgendwo Mist gebaut hat, z.B. ne Barrier oder andere Synchronisierungs-Massnahmen vergessen hat), wenn man Delay-Schleifen baut um die CPU für ein paar Mikrosekunden zu beschäftigen oder ähnlich fragwürdige Dinge.

Wie gesagt ich finde die Frage berechtigt

Ja, vollkommen berechtigt. Mich hat nur etwas irritiert dass - nach der Antwort auf die eigentliche Frage - dann so lange wegen der Einfärbung in der IDE rumdiskutiert wurde.
Das meinte ich mit "ich verstehe das Problem nicht"

Ja, vollkommen berechtigt. Mich hat nur etwas irritiert dass - nach der Antwort auf die eigentliche Frage - dann so lange wegen der Einfärbung in der IDE rumdiskutiert wurde.
Das meinte ich mit "ich verstehe das Problem nicht"

Ich dachte (aufgrund des Folgesatzes) imo berechtigt, dass du dich eher auf die Optimierungsfrage bezogen hast. Die Einfärbung hätte mich auch verwirrt und ich finde das Feature ein wenig überflüssig (zumindest unter VS), da dort der Compiler einer Warnig ausgibt und der vertraue ich eher, als einem IDE Parser.
(Obwohl VS2010 hat, denke ich was ähnliches drin.. Da wird dann einfach rot gewellt unterstrichen. :p)