c++ Frage

[dimevit]

Hallo zusammen,

weiss jemand, was das folgende für eine c++ struktur ist:

double test= (1,2,3);
std::cout<< test; => bekomme ich 1

ich benutze IPopt für nicht-lineare optimierung und dachte mir, so was wird da als Matrix erkannt. Aber dann hat es auch ganz normal funktioniert und ich weiss nicht was das ist. Weiss jemand?

MfG
Dime

[locus vivendi]

weiss jemand, was das folgende für eine c++ struktur ist:

double test= (1,2,3);
std::cout<< test; => bekomme ich 1

Wenn du dort 1 bekommst hast du einen kaputten Compiler.

Im Übrigen handelt es sich u.a. um eine Anwendung des Komma-Operators. Der bindet von Links nach Rechts und dessen Wert ist gleich der rechten Seite. Außerdem werden die meisten Seiteneffekte der linken Seite vor der rechten Seite ausgewertet.

[tribad]

Naja. Das in den Klammern ist eine Parameterliste für ne funktion. Das geht schon ist nur völlig sinnlos. Ich hab sowas mal gemacht um die Debug ausgaben zu entsorgen. Einfach ein define der Debugfunktion nach nichts.

Ich weiß nicht, ob das noch dem aktuellen Standard entspricht. Aber vor 15 Jahren war das OK. Aber auch nur in C.

Das da ein Wert rauskommt ist wahrscheinlich Zufall. Vielleicht sollte er die Variable mal global mit 0 initialisieren. Die sollte sich eigentlich nicht verändern.

Der Compiler ist nicht kaputt sondern er nimmt es nicht mit dem Standard so genau.

[nul]

tribad hat im Prinzip recht, und C, bzw. C-Funktionen wie printf sollten meines Wissens nach hier auch 0 ausgeben.
Dabei ist mir aber folgendes aufgefallen:
printf("%d\n", test) - ob mit gcc oder g++ kompiliert gibt immer 0 aus
std::cout << test << std::endl (natuerlich nur g++) gibt 3 aus ?!?

Kann das vielleicht jemand bestaetigen?
Kompiler sind jeweils:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

und

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

[sommerfee]

tribad hat im Prinzip recht, und C, bzw. C-Funktionen wie printf sollten meines Wissens nach hier auch 0 ausgeben.

Nein, AFAIK nicht. Das Komma hat nunmal in C eine Doppelbedeutung, die unterschiedlich ist, je nachdem ob er zum Trennen von Argumenten bei einem Funktionsaufruf oder innerhalb eines Ausdrucks als Kommaoperator benutzt wird.

Man beachte z.B. folgenden, völlig C-konformen Code:

char a[16];
strcpy( a, ("Hallo","Huhu") );
printf( "a = %s\n", a );

Dabei ist mir aber folgendes aufgefallen:
printf("%d\n", test) - ob mit gcc oder g++ kompiliert gibt immer 0 aus

Wenn "test" vom Typ "double" ist, muß es "%lf" und nicht "%d" im printf-Ausdruck heißen. Manche Compiler bzw. lint geben hier auch eine Warnung aus, wenn der Typ nicht stimmt.

Gruß,
Axel

[nul]

Nein, AFAIK nicht. Das Komma hat nunmal in C eine Doppelbedeutung, die unterschiedlich ist, je nachdem ob er zum Trennen von Argumenten bei einem Funktionsaufruf oder innerhalb eines Ausdrucks als Kommaoperator benutzt wird.

Man beachte z.B. folgenden, völlig C-konformen Code:

char a[16];
strcpy( a, ("Hallo","Huhu") );
printf( "a = %s\n", a );



Wenn "test" vom Typ "double" ist, muß es "%lf" und nicht "%d" im printf-Ausdruck heißen. Manche Compiler bzw. lint geben hier auch eine Warnung aus, wenn der Typ nicht stimmt.

Gruß,
Axel

Stimmt, zu lange nichts mehr mit C gemacht, daher die verwechslung von %d und %lf.

[sommerfee]

Der Compiler ist nicht kaputt sondern er nimmt es nicht mit dem Standard so genau.

Wo siehst du da den Unterschied? Für mich ist das das gleiche; wenn er vom Standard abweicht, ist das ein Fehler im Compiler.

Liebe Grüße,
Axel

[tribad]

Wo siehst du da den Unterschied? Für mich ist das das gleiche; wenn er vom Standard abweicht, ist das ein Fehler im Compiler.

Liebe Grüße,
Axel

Also der gcc-3.x weicht vom Standard ab. Aber deswegen isser nicht kaputt. Immerhin sind damit unmengen an Software erfolgreich übersetzt worden.
Kaputt bedeutet bei mir, das man damit keine Software korrekt, also im Sinne des Programmierers, übersetzen kann.

Im allgemeinen werden die Standards stetig überarbeitet. was unweigerlich bedeuten würde, da somit alle Compiler die sich nicht mehr an den Standard halten von einem Moment zum anderen kaputt wären.

Kaputt halte ich daher für eine sehr pauschale Aussage. Die Standards bekommen jeweils entsprechende Bezeichnungen. Somit kann man eine Aussage treffen, ob ein Compiler einem Standard mit einer bestimmten Bezeichnung entspricht.

Ich habe zu Hause eine HP9000-300 mit HP-UX 6.xx. Da ist ein C-Compiler drauf, der keine 100KB groß ist. Mit dem lassen sich hervorragend C-Programme übersetzen, solange sie Old-Style funktions definitionen benutzen. Die Fehlermeldung beschränkt sich auf ,,syntax error''. Aber er funktioniert. Er entspricht dem damaligen Stand, da es damals noch keinen Standard der Sprache C gab.

Er ist nicht kaputt. Nur nicht ganz dem Standard entsprechend.

[locus vivendi]

Zitat von sommerfee Beitrag anzeigen
Wo siehst du da den Unterschied? Für mich ist das das gleiche; wenn er vom Standard abweicht, ist das ein Fehler im Compiler.

Liebe Grüße,
Axel

Also der gcc-3.x weicht vom Standard ab. Aber deswegen isser nicht kaputt. Immerhin sind damit unmengen an Software erfolgreich übersetzt worden.
Kaputt bedeutet bei mir, das man damit keine Software korrekt, also im Sinne des Programmierers, übersetzen kann.

Im allgemeinen werden die Standards stetig überarbeitet. was unweigerlich bedeuten würde, da somit alle Compiler die sich nicht mehr an den Standard halten von einem Moment zum anderen kaputt wären.

Nein, der letzte Absatz stimmt überhaupt nicht. Das habe ich nicht so behauptet und Sommerfee auch nicht, es sei denn man interpretiert ihn sehr ungünstig.
Ich habe ein konkretes Beispiel genannt dessen Fehl-Kompilierung einen Compiler als kaputt zu bezeichnen rechtfertigt. Du machst daraus das bei jeder Abweichung vom Standard kaputt zutreffend wäre. Das habe ich nicht geschrieben. Ich kann "nicht mehr aktuell" nämlich auch von "kaputt" unterscheiden.