#include <iostream>
using namespace std;

int i = 5;

void fkt(const int& ref)
{
	cout << '\n' << "Adresse des Temporary: " << &ref;

	cout << '\n' << "Wert des Temporary: " << ref;
	i = 10;
	cout << '\n' << "Wert des Temporary: " << ref;
}

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

	fkt( int(i) );
}

Visual C++ Compiler:

Adresse von i        : 00CF3000
Adresse des Temporary: 00CF3000
Wert des Temporary: 5
Wert des Temporary: 10

GCC:

Adresse von i        : 0x470000
Adresse des Temporary: 0x28ff1c
Wert des Temporary: 5
Wert des Temporary: 5

Fazit:
- Visual C++ Compiler erzeugt bei int(i) kein Temporary und die Funktion fkt arbeitet mit dem globalen i .
- GCC erzeugt bei int(i) ein Temporary (genauso, wie es sich gehört) und die Funktion fkt arbeitet mit einer Kopie des globalen i .

Wieder mal ein Bug des Visual C++ Compilers, oder was sagt ihr dazu?

Und wo soll da jetzt der Bug sein?

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

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.

Könnte der Compiler das Optimiert haben?

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.

Könnte der Compiler das Optimiert haben?

Ich habe mit VS 2010 im Debug-Modus kompiliert. Da ist die Optimierung ja deaktiviert.

#include <iostream>

void func(int&& a)
{
        std::cout << "RVAL";
}

void func(int const& a)
{
        std::cout << "REF";
}

int i(5);

int main()
{
        func( int(i) );
}

GCC 4.6.2 sagt RVAL.

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.

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?

Was für ein Fundstück!

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?

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.

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.

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.

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.