Frage an die C++-Programmierer

[Ricky Spanish]

Moin.

Wenn ich folgende Zeile im Code stehen habe (ohne irgendwas davor oder dahinter):

("asdf");

Dann kompiliert mein MinGW C++ Compiler das ohne Probleme. Ich frage mich gerade nur: WIESO? Und vor allen Dingen: Was um Himmels Willen macht der da für einen Maschinenbefehl draus?

Das ist weder ne Zuweisung, noch ein Funktionsaufruf noch irgendetwas anderes, was auch nur im entferntesten Sinn machen würde.

Jemand eine Idee, warum ich damit nicht auf einen Compilerfehler laufe?

Gruß
m.a.k.

P.S.: Das ganze geht auch mit abenteuerlichen Konstrukten wie z.B. ("Du", " ", "dummer", " ", "Compiler");

 

[PiZzA]

naja.

was bereitet dir daran jetzt genau kopfzerbrechen?

 

[Ricky Spanish]

zwei dinge:

(i) ist das compiler-abhängig und bekomme ich evtl. mit anderen compilern später fehlermeldungen beim kompilieren?
(ii) kosten solche statements performance oder werden sie beim kompilieren vom compiler einfach ignoriert?

hintergrund ist folgender: das ganze soll zum debugging unserer 3D engine dienen und wir wollen die debug statements nachher per define wieder entfernen können, damit wir in der fertigen version keine performance einbußen haben...

 

[Wesen]

Original geschrieben von m.a.k.
(i) ist das compiler-abhängig und bekomme ich evtl. mit anderen compilern später fehlermeldungen beim kompilieren?

Schau im Standard nach ?
Ist IIRC aber nicht Compilerabhängig.

(ii) kosten solche statements performance oder werden sie beim kompilieren vom compiler einfach ignoriert?

Schau dir den assembler output deines Compilers an ?
Aber nein, was für Code soll denn da generiert werden ? Schlimmstenfalls werden die Strings irgendwo in der exe gespeichert, aber zumindest in einem optimierten build und mit einem nicht total schlechten Kompiler sollte auch das nicht passieren.

hintergrund ist folgender: das ganze soll zum debugging unserer 3D engine dienen und wir wollen die debug statements nachher per define wieder entfernen können, damit wir in der fertigen version keine performance einbußen haben... [/B]

Wenn das ganze nachher ohnehin ca. so aussehen soll:

#ifdef DEBUG
#define debug(x) { [...] output(x); }
#else
#define debug(x)
#endif

bleibt davon in release builds ohnehin nichts übrig.

 

[Whcttyh]

ein compiler sollte imstande sein eine warnung auszugeben, schließlich sind das normalerweise programmierfehler. wenn als anweisung ein ausdruck wie 1 erlaubt ist, ist natürlich auch sowas wie (1,2,3) erlaubt. maschinenbefehle werden nicht erzeugt, compiler läuft aber langsamer.

 

[Picard]

das ist doch einfach nen statement dass du machst. es ist kompatibel mit der syntax - es passiert aber halt nix.

läuft aufs selbe drauf raus als würdest du

123;
true;

/* klammerungen sind ja auch beliebig und geben nur die "reihenfolge" der ausdrücke an, siehe: */
(("a"),"sdf");

// und um nicht zu vergessen:
;

aufschreiben
wenn du z.b. ne klammer vergisst wird es auch nen error geben, aber so sind es einfach nur valide ausdrücke (ohne sinn - aber das ist deinem rechner egal bzw kann er das ja nicht wissen)
wie das ganze im assembler aussieht weis ich nun allerdings auch nicht, vielleicht wird ja nen NOP draus

 

[PiZzA]

was mich daran nur wundert sind die , im zweiten beispiel, die müssten eigentlich nen fehler ausgeben....

oder ist das nur ein tippfehler und es sollte eig. ein ; stehen

achso langsamer kannste vergessen wirds nicht...

 

[Picard]

nö das is quasi ne "aufzählung" wie z.b. bei funktionsparametern, arrays oder dem initialisieren mehrerer variablen eines typs z.b. durch int a, b, c;

beispiel:

cout << "asdf", "qwerty" << endl;

gibt nur "asdf" aus.

is ja genauso wie du selbst "blöcke" erzeugen kannst

// ohne das jetzt was davor steht 

{
   // pseudo code
   {
   /* more pseudo code 
       ......
    */
   }
}

ist halt einfach ein element der sprachdefinition von c++ wobei sich über sinn und unsinn streiten lässt, syntaktischer fehler aber deswegen noch lange nicht

 

[Whcttyh]

hm, glaube nicht, dass das funktioniert. mit ',' kann man eine reihe von ausdrücken angeben, die von links nach rechts ausgewertet werden. wegen sehr geringer priorität des ',' sollte man klammern verwenden. folgendes gibt 3 aus:
int x;
std::cout << (x=1, x+=1, x+1) << std::endl;

 

[Picard]

jo k mein beispiel war ja auf strings bezogen (und getestet mit vs pro 2005)

 

[Whcttyh]

komischer compiler das vs ding (oder ich verstehs nur nicht).

edit: grad mal getestet. gcc erlaubt die operanden für << nicht. naja auch egal.

 

[Ricky Spanish]

Original geschrieben von Pikkart
wie das ganze im assembler aussieht weis ich nun allerdings auch nicht, vielleicht wird ja nen NOP draus

genau das ist der springende punkt!
wenn da wirklich ein NOP draus wird, dann kostet das nachher rechenzeit. und wenn das so ist, dann ist das natürlich im core einer 3D-engine ziemlich scheisse.

leider fehlt mir momentan die zeit, mit nem dissassembler dran zu gehen und mir den erzeugten maschinencode anzuschauen...

Original geschrieben von PiZzA
achso langsamer kannste vergessen wirds nicht...

glaubst du das oder weißt du das mit sicherheit?

Original geschrieben von [UEP]Xyz
maschinenbefehle werden nicht erzeugt

selbe frage wie oben: vermutung oder sicheres wissen?

 

[Wesen]

VS2005 erzeugt definitiv (zumindest im ganz simplen fall) keine maschinenbefehle, hab das gerade mal getestet. Diese Anweisungen direkt zu entfernen ist auch so simpel dass ich nicht glaube dass das irgendwo anders ist.

Aber irgendwie interessiert mich ja immernoch wie das Konstrukt aussehen soll dass nachher in einem Release build überall solche Codeschnipsel hinterlässt.

 

[Ricky Spanish]

Original geschrieben von Invincible[UFF]
VS2005 erzeugt definitiv (zumindest im ganz simplen fall) keine maschinenbefehle, hab das gerade mal getestet. Diese Anweisungen direkt zu entfernen ist auch so simpel dass ich nicht glaube dass das irgendwo anders ist.

ok, danke das ist ne klare aussage
dann sollte das eigentlich mit dem mingw genauso sein.

Original geschrieben von Invincible[UFF]
Aber irgendwie interessiert mich ja immernoch wie das Konstrukt aussehen soll dass nachher in einem Release build überall solche Codeschnipsel hinterlässt.

leider hab ich gerade von hier aus keinen zugang zum source-code, daher muss ich es textuell beschreiben:

wir haben ne logging funktion. die funktioniert im prinzip genau wie die printf-funktion. du gibst ihr eine variable anzahl von parametern und einen string mit platzhaltern mit und die funktion loggt das ganze schön formatiert in eine html-datei.

um das ganze übersichtlicher zu gestalten, bekommt die funktion außerdem den namen der source-code-datei und die aktuelle zeile mit, von der aus sie aufgerufen wird. das ist gerade für's debugging recht nützlich.

das wird natürlich mit einem makro über define gemacht.

das problem ist nur: leider kann man makros nicht überladen und man kann auch keine makros mit einer variablen anzahl von parametern erstellen.

einzige lösung ist also, dass das makro lediglich den funktionsnamen ersetzt und __FILE__ / __LINE__ dranhängt, aber die parameter stehen bleiben.
wenn nun das define rausfliegt, dann ist klar was passiert: Aus z.B. LOGDEBUG("Eine %s-Nachricht", "DEBUG"); wird nach entfernen des markos ("Eine %s-Nachricht", "DEBUG");...

 

[Wesen]

Original geschrieben von m.a.k.

das problem ist nur: leider kann man makros nicht überladen und man kann auch keine makros mit einer variablen anzahl von parametern erstellen.

#define log(...) printf(__VA_ARGS__ )

ist ein makro mit variabler parameterzahl

Aber okay, jetzt seh ich zumindest wie man zu dem problem kommt

 

[Ricky Spanish]

Original geschrieben von Invincible[UFF]

#define log(...) printf(__VA_ARGS__ )

ist ein makro mit variabler parameterzahl

Aber okay, jetzt seh ich zumindest wie man zu dem problem kommt

was soll ich sagen, außer: DANKE

mir war nicht bekannt, dass das möglich ist. und wieder hab ich was dazu gelernt