Visual C++ Compiler erzeugt kein Temporary. Bug?

Kellerautomat

Und was soll das beweisen? Der Standard sagt, dass RVAL rauskommen soll.

camper schrieb:

Gugelmoser schrieb:

SG1 schrieb:

Und wo soll da jetzt der Bug sein?

Dass der eine Compiler bei int(i) ein temporäres Objekt erzeugt, und der andere nicht.

int(i) erzeugt kein temporäres Objekt, ist allerdings ein prvalue.
Wenn ein solches skalares prvalue an eine Referenz gebunden wird, muss ein temporary erzeugt werden (schließlich verweist jede Referenz auf ein Objekt und ein skalares rvalue ist kein Objekt). vc++ tut das offenbar nicht.

Sollte ich MS den Bug melden?

Wie konnte der Bug jahrelang verborgen bleiben?

Was für ein Fundstück!

ipsec

camper schrieb:

Wenn ein solches skalares prvalue an eine Referenz gebunden wird, muss ein temporary erzeugt werden (schließlich verweist jede Referenz auf ein Objekt und ein skalares rvalue ist kein Objekt).

Fällt das nicht unter as-if?

camper

ipsec schrieb:

Fällt das nicht unter as-if?

Solange sich das beobachtete Verhalten nicht ändert. i und das temporäre Objekt sind verschieden, haben aber eine sich überschneidene Lebensdauer.. Also müssen auch deren Adressen verschieden sein. Mit vc++ ist etwas anderes zu beobachten.

Jonas OSDever

Anscheinend ist es trotzdem eine Art Optimierung, auch wenn Optimierungen deaktiviert sind.

Konventiert man zum Beispiel zu short, so funktioniert alles wieder:

//...
int main()
{
    cout << '\n' << "Adresse von i        : " << &i;

    fkt( short(i) );

	cin.get();
}

Adresse von i        : 00419000
Adresse des Temporary: 0012FEA0
Wert des Temporary: 5
Wert des Temporary: 5

Wenn ich i als short deklariere und dann wie im Ausganspost fkt(int(i)); aufrufe, funktioniert es auch noch:

Adresse von i        : 00419000
Adresse des Temporary: 0012FEA0
Wert des Temporary: 5
Wert des Temporary: 5

Wenn ich i als short deklariere und den geänderten Aufruf fkt( short(i)); benutze, dann funktioniert es trotzdem:

Adresse von i        : 00419000
Adresse des Temporary: 0012FEA0
Wert des Temporary: 5
Wert des Temporary: 5

Wenn ich die Veränderungen wie gerade eben lasse und zusätzlich die Funktionissignatur von fkt nach void fkt( const short& ref) abändere, findet sich wieder der Bug:

Adresse von i        : 00419000
Adresse des Temporary: 00419000
Wert des Temporary: 5
Wert des Temporary: 10

Fazit: Ist anscheinend eine gut gemeinte Optimierung des Compilers, die auch bei abgeschalteter Optimierung wirkt, wenn Typ der Variable, des gewünschten temporären Objekts und des Funktionsargumentes gleich sind.

Ich habe eben versucht den Bug zu melden. Will ich einen Thread bei denen im Forum erstellen, bekomme ich aber immer den Fehler "unexpected error". Falls jemand Lust hat, kann derjenige es ja mal versuchen.

hustbaer

Language-Extensions deaktiviert?
MSVC erlaubt mit Extensions (die per Default an sind) das Binden von (LValue) Referenzen an RValues. Zumindest bis MSVC 2008, wird bei 2010 dann vermutlich nicht anders sein.

hustbaer schrieb:

Language-Extensions deaktiviert?
MSVC erlaubt mit Extensions (die per Default an sind) das Binden von (LValue) Referenzen an RValues. Zumindest bis MSVC 2008, wird bei 2010 dann vermutlich nicht anders sein.

Du hast Recht.
Wenn ich Language-Extensions deaktiviere (Konfigurationseigenschaften --> C/C++ --> Sprache --> Spracherweiterungen deaktivieren = Ja(/Za)) ist alles wieder standardkonform.

Danke für den Hinweis, hustbaer.

Gugelmoser schrieb:

Wenn ich Language-Extensions deaktiviere (Konfigurationseigenschaften --> C/C++ --> Sprache --> Spracherweiterungen deaktivieren = Ja(/Za)) ist alles wieder standardkonform.

Na super, jetzt spruckt er wegen boost lauter Warnungen aus, weil /Za offensichtlich broken ist. Das ist doch eine Scheiße. MS raubt mir auch noch den letzten Nerv.

hustbaer

Auf jeden Fall kannst du dir jetzt sparen den "Bug" zu reporten - ist schliesslich dokumentiertes und "erwünschtes" Verhalten.