spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »NachoMan«

wird eigentlich während des kompilierens oder erst danach optimiert?

teils, teils. bei Visual C++ kann man zum einen beim Compiler einiges an Optimierung einstellen, zum anderen aber auch einige Dinge beim Linker. z.B. kann man den nicht verwendete Symbole entfernen lassen, was dann glaub ich bedeutet, das ncith aufgerufene Funktionen tatsächlich entfernt werden.

Zitat von »NachoMan«

edit: wenn das stimmt was PCShadow schreibt, warum gibt es bei deklarierten aber nicht definierten funktionen einen linkerfehler und keinen kompilerfehler?

der Compiler betrachtet immer nur eine Übersetzungseinheit, eine .cpp nach Präprozessor, also das, was aus .cpp und #includes entsteht. Die funktion könnte aber in einer anderen definiert sein, also setzt der Compiler dort nur einen externen Verweis. Und der Linekr löst dann diese externen Verweise auf - oder beschwert sich eben, wenn er einen ncith findet.

das heißt der kompilierte code wird in assemblerform bei den richtigen einstellungen nochmal optimiert bevor er durch den assembler gejagt wird?

hm, ich glaub eher, das der Compiler schon im wesentlichen Maschinencode produziert, nru mit zusätzlichen informationen, dei der Linker benutzt, um externe Verweise aufzulösen und vllt noch n bischen zu optimieren.

Zitat von »idontknow«

Werd mich dran halten, muss aber zu meiner Verteidigung sagen dass ich geschrieben habe

Funktion/Methode; Klasse

Und im Code kam zuerst eine leere Funktion, dann eine Klasse mit eienr leeren Methode und dann eine leere Klasse hab das für leicht verständlich gehalten x/

Woher sollen wir wissen, was du genau meinst mit "Funktion/Methode; Klasse"?!

Optimierung ist schon ein heikles Thema. Vor allem bei Inlining Sachen kann der Compiler nicht wirklich etwas machen, wenn er den genauen Code nicht kennt.
Interessanter Artikel gibts heir:
http://msdn.microsoft.com/en-us/magazine/cc301698.aspx

Zitat von »-insane-«

	C-/C++-Quelltext
1 2 3 4	void foo(void) { };

Der Code wird mitkompiliert und das Programm führt diese Funktion auch aus, aber da sie nichts macht, passiert auch nichts weiter und das Programm wird weiter ausgeführt. D.h. es wird kurz reingesprungen und dann wieder raus. Das sieht man z.B. wenn man nen Breakpoint in die Funktion setzt und den Debugger startet.

Das ist so nicht richtig !
Kompilier mal mit Optimierungen und Debug-Informationen und dann step nochmal da durch.

Bei GCC4 fällt sowas komplett raus, da steht dann auch kein asm-noop, geschweige denn irgendwas.

Zitat von »FalkT«

Bei GCC4 fällt sowas komplett raus, da steht dann auch kein asm-noop, geschweige denn irgendwas.

Aber nur in der gleichen Compilation Unit. Da gilt genau das was bisher geschrieben wurde. Die aktuellen (stable) Versionen von GCC erzeugen Maschinencode (mit Assembler als Zwischenschritt), bei dem zum Zeitpunkt des Linkens nicht mehr die nötigen Informationen vorhanden sind, um Funktionsaufrufe zu entfernen. Mit Version 4.5 (seit kurzem als Release Candidate zu bekommen) bekommt der GCC allerdings auch die Möglichkeit in einen Bytecode zu compilieren, der dann beim Linken in Maschinencode umgewandelt wird. Dann können dort auch unnötige Funktionsaufrufe entfernt werden.

Wie wärs mit Thread lesen, bevor man posted?