Spinnt mein Vc++ 2005 Express Edition Compiler

Hoi,

Ich benutze die Visual C++ 2005 Express Edition.
Jetzt habe ich eine Frage.
Warum compiliert er ohne Murren folgenden Code.

class foo
{
public:
    int a;
}

void(foo& arg)
{
    arg.a=123;
}

int main(void)
{

    func(foo()); //<------ in der Funktion verändere ich ein Attribute 
                 //aber foo() bleibt doch immer foo(), da müsste doch eg
                 //ein const noch hin oder

    return 0;
}

lolz

Ist kein Standard-C++, aber der VC++ erlaubt es. In der 7.1er Version warnt er allerdings, sollte er daher auch im 8er machen.

Knuddlbaer

Hm,

ich sehe da kein Fehler im Code. Das foo() ein temporäres Objekt ist,
sieht die Funtkion nicht.

Mir fällt jetzt auch nichts ein, was verbieten würde ein temporäres Objekt an die Funktion zu übergeben.

camper

Ich nehme an, der code soll so aussehen (damit wir über dasselbe reden):

class foo
{
public:
    int a;
};

void func(foo& arg)
{
    arg.a=123;
}

int main(void)
{

    func(foo()); //<------ in der Funktion verändere ich ein Attribute
                 //aber foo() bleibt doch immer foo(), da müsste doch eg
                 //ein const noch hin oder

    return 0;
}

Das ist, wie erwähnt, eine Spracherweiterung des Microsoft-Compilers, die wohl hauptsächlich aus Kompatibilitätsgründen zu füheren Compilerversionen beibehalten wird. Die Behauptung, dass das völlig still akzeptiert wird, ist im übrigen nicht richtig. Da ist einerseits die Level 4 Warnung C4239, zum anderen wird diese Art von Konstruktion, wie die anderen Erweiterungen von Microsoft, nicht akzeptiert, wen der Schalter /Za aktiv ist.

Knuddlbaer schrieb:

Hm,

ich sehe da kein Fehler im Code. Das foo() ein temporäres Objekt ist,
sieht die Funtkion nicht.

Mir fällt jetzt auch nichts ein, was verbieten würde ein temporäres Objekt an die Funktion zu übergeben.

Temporäre Objekte sind nicht das Problem, sondern rvalues (auch wenn Ersteres in der Regel Letzteres bedeutet). Ein rvlaue kann nicht an eine Referenz auf nicht-const gebunden werden. Legal wäre zum Beispiel das hier, trotz temporärer Objekte

func(foo()=foo());

Also der g++ meckert da immer rum und gibt Fehler aus?
Wer hat jetzt "mehr" Recht Gnu oder Microsoft?

Hoi, ich habe auch eine Frage die teils zu diesem Thema passt, deshalb wollte ich nicht noch einen neuen Threat aufmachen.

Wenn man per foo() ein temporäres Object erstellt, wielange bleibt dieses bestehen?

int main()
{
    func(foo()); // <-Dieses foo() bleibt es so lange bestehen wie 
                 //die Funktion andauert?
}

Knuddlbaer

Temporäre Objekte sind nicht das Problem, sondern rvalues (auch wenn Ersteres in der Regel Letzteres bedeutet). Ein rvlaue kann nicht an eine Referenz auf nicht-const gebunden werden. Legal wäre zum Beispiel das hier, trotz temporärer ObjekteC/C++ Code:
func(foo()=foo());

Ah ok, werde mich mit dem Thema l und rvalue noch mal auseinander setzen müssen.

Wenn man per foo() ein temporäres Object erstellt, wielange bleibt dieses bestehen?

In dem Beispiel, bis die Funktion beendet wird.

camper

Ulo schrieb:

Wenn man per foo() ein temporäres Object erstellt, wielange bleibt dieses bestehen?

Bis zum Ende der Auswertung des vollständigen Ausrucks, in dem es steht.

groovemaster

asdfgfggh schrieb:

Also der g++ meckert da immer rum und gibt Fehler aus?
Wer hat jetzt "mehr" Recht Gnu oder Microsoft?

Recht wobei? Beide Compiler akzeptieren das nicht als Standard C++. Punkt.