kurz 2 Linkerfragen:

1. Wenn ich 2 UE a.cpp und b.cpp habe und es in b.cpp eine Funktion bFunc() gibt, die aus a.cpp die Funktion aFunc() aufruft, dann wird ja vom Compiler sowaas erzeugt: CALL XXXXX und der Linker trägt dann für XXXXX die Adresse von aFunc() ein.
Aber wie ist das, wenn ich in b.cpp in der Funktion bFunc() eine andere Funktion aus b.cpp aufrufe, z.b. AnotherBFunc(). Generiert der Compiler dann gleich beim Übersetzen von b.cpp Code mit der Adresse oder wieder nur CALL XXXXX? (Ich tippe auf Letzteres)

2. Geht ein C++ Compiler genau einmal über eine UE? Oder mehrere Male wenn nötig (Ich tippe auf ersteres)

Danke!

Was das "single pass" vs. "multi pass" angeht: ich würde sagen ein klassischer "single pass" Compiler für C++ ist unmöglich.

1. Es gibt den Präprozessor. Ob dieser Teil des "Compilers" ist ist Ansichtssache. Vom Standard vorgeschrieben ist er, Teil des gesamten Übersetzungsvorganges muss er daher immer sein, also denke ich sollten wir ihn dazurechnen. Den Präprozessor sollte man natürlich "streamlinen" können, d.h. dieser allein macht noch keinen 2. Pass notwändig.

2. Es gibt Templates, und Templates viele Dinge machen die von Template-Parametern abhängig sind. Das "Instanzieren" von Templates ist etwas was in dem was ich mir unter einem klassischen "single pass" Compiler vorstelle nicht möglich ist. Natürlich muss der Compiler um ein Template zu instanzieren nicht 1:1 den Source-Code nochmal durchackern, aber gewisse Datenstrukturen die er beim parsen des Template-Codes erzeugt hat muss er dazu zumindest durchackern. Natürlich muss ein Compiler das auch wenn irgendwo ein Funktionsaufruf steht -- dazu muss er ja wissen welche Funktionen mit einem bestimmten Namen etc. es gibt. Beim Instanzieren von Templates muss aber wesentlich mehr passiere: es muss wirklich "Code" (in irgendeiner Form) interpretiert werden. Das sieht man auch schon daran was man mit Templates alles anfangen kann (z.B. diverse Berechnungen "statisch", also beim Compilieren, durchzuführen, und nur das fertige Ergebnis "ins Programm zu compilieren", oder auch die Auswahl eines bestimmten Typs von solchen Berechnungen abhängig zu machen).
   Weiters kann man in C++ Code auf viele Dinge zugreifen die "weiter unten im Code stehen", auch ohne forward-declarations. Ein Beispiel sind Member von Klassen, auf die man in inline implementierten Funktionen zugreift. Sowas:

int a;
int b;
int c;

class bar
{
public:
   void test()
   {
       a += char(0); // bar::a, einfache integer addition
       b += char(0); // bar::b, std::string::operator += (char)
       c += char(0); // globales ::c, einfache integer addition
       // ...
   }

private:
   int a;
   std::string b;
};

Weiters optimieren viele Compiler, und für Optimierungen ist es oft nötig den selben Code mehrfach anzuschauen. Beispielsweise gibt es Compiler die Funktionen inline erweitern können, und zwar auch an Stellen im Code wo der Compiler die Implementierung der Funktion "noch garnicht gesehen hat". Ein klassischer "single pass" Compiler kann auch das nicht.

Die Antwort auf deine Frage hängt also davon ab was du unter "einmal drübergehen" verstehst. Wenn du meinst dass der Compiler nur 1x genau den Text durchgeht, 1:1 so wie er in den Source-Files drinsteht, dann gibt es vermutlich viele Compiler die das so machen. (Diese Compiler "parsen" den Source-Code indem sie genau 1x über den Quelltext drübergehen, erzeugen sich dabei interne Datenstrukturen, und arbeiten dann im Weiteren nur mit diesen internen Datenstrukturen. Sozusagen.)

Wenn du damit allerdings meinst, dass, nachdem der Compiler das letzte Zeichen einer Funktion oder Klasse "verarbeitet" hat, der komplette "Code" für diese Funktion oder Klasse feststeht, dann ganz klar nein.

// a.cpp
void bar();

void foo() {
   bar();
}

void bar() { }

Erzeugt dann der Compiler beim Übersetzen von a.cpp gleich ein call AdresseVonBar oder nur ein call XXXXX und der Linker ersetzt dann XXXXX durch die Adresse von bar?

---

In deinem Beispile kann ich dir sagen dass z.B. MSVC (mit Optimierungen an) keines von beiden machen wird: er wird den Aufruf von bar() gleich ganz weglassen -- wozu eine Funktion aufrufen die *nichts* macht?

http://msdn.microsoft.com/en-us/magazine/cc301698.aspx

Jetzt wirst du wieder fragen "ja, aber was wenn MSVC die Funktion NICHT inlinen kann?". Dann werde ich antworten: das kommt u.U. auch auf die Compiler-Einstellungen drauf an.

Wieso willst du das überhaupt so genau wissen? (würde mich nur interessieren - bestimmter Grund oder einfach Neugier)

Dass theoretisch beides möglich ist solltest du aus meinen Antworten ja bereits rausgelesen haben.

Davon abgesehen...

Ich habe jetzt nachgesehen: x86 Code verwendet bei direkten Sprüngen normalerweise relative Adressen, d.h. der Compiler *könnte* gleich die fertige (relative) Adresse reinschreiben. Ich hatte das anders in Erinnerung - da sieht man mal wieder wie man sich täuschen kann
(x64 verwendet vermutlich ich auch relative Adressen)

Was ich aber sicher weiss: mit Function-Level-Linking (Compiler Option) *muss* der Linker die Adresse nochmal anpassen, da auch die relative Adresse einer Funktion in der selben Übersetzungseinheit sich beim Linken ändern kann.

Function-Level-Linking: http://msdn.microsoft.com/en-us/library/xsa71f43(VS.80).aspx

Und ich bin mir ziemlich sicher dass auch ohne Function-Level-Linking der Linker die Adresse nachträglich anpassen wird. Garantieren kann ich es allerdings nicht.

hustbaer schrieb:

Wieso willst du das überhaupt so genau wissen? (würde mich nur interessieren - bestimmter Grund oder einfach Neugier)

Hauptsächlich aus reiner Neugier.

Aber die 2. Frage entstand, weil ich mich gefragt habe wieso ich überhaupt Prototypen brauche, wenn ich eine Funktion aufrufe? In Java oder C# brauch ich die ja auch nicht. In C++ liefert das ja schon einen Compilefehler:

void bar() { foo(); }

void foo() { }

Das kann ich mir eigentlich nur dadurch erklären, dass der C++ Compiler (MSVC) nur einmal über die UE geht. Würde er z.B. einfach 2mal drübergehen, dann hätte er ja beim 2. Durchlauf die Definition von foo() und könnte bar() übersetzen.

Was du mit relativen Adressen bei Sprüngen meinst, ist mir nicht klar. Die Windows PE Dateien benutzen bei Calls und JMPs alle absolute Adressen (die zur Not reallokiert werden, wenn die BaseImageAdresse != AdresseImVirtSpeicherAnDieDasExecutableGeladen wird)

Das kann ich mir eigentlich nur dadurch erklären, dass der C++ Compiler (MSVC) nur einmal über die UE geht. Würde er z.B. einfach 2mal drübergehen, dann hätte er ja beim 2. Durchlauf die Definition von foo() und könnte bar() übersetzen.

Das hat eher historische Gründe, und weniger damit zu tun, was der Compiler tun könnte und nicht tun könnte. Viele Dinge, die heutige C++ Compiler tun könnten, sind laut Standard "falsch", und werden daher von Compilern auch als Fehler behandelt. Dass der Compiler Funktionen, die in der selben UE definiert werden, auch ohne Prototyp "verstehen" kann, sieht man ja auch daran, dass es mit implizit inline implementierten Memberfunktionen funktioniert.

Was du mit relativen Adressen bei Sprüngen meinst, ist mir nicht klar. Die Windows PE Dateien benutzen bei Calls und JMPs alle absolute Adressen (die zur Not reallokiert werden, wenn die BaseImageAdresse != AdresseImVirtSpeicherAnDieDasExecutableGeladen wird)

Mit relativen Sprüngen meine ich relative Sprünge . Das PE Format kann beim "re-basen" absolute Adressen anpassen, das heisst aber nicht dass jeder Sprung/Call absolut adressiert sein muss. Im Gegenteil, alles was relativ adressiert werden kann wird normalerweise auch relativ adressiert. Schonmal deswegen, weil der Code für einen relativen Sprung kleiner ist, und auch weil so der Relocation Table nicht unnötig aufgeblasen wird. Guck dir einfach mal an, was MSVC für Code generiert, dann wirst du sehen, dass an vielen Stellen relative Adressen verwendet werden. (Du brauchst z.B. bloss mal im Debugger den disassemblierten Code anzeigen lassen, da lässt sich leicht erkennen was relativ und was absolut adressert wird)

Relativ bedeutet in dem Fall dass nur ein Offset zur Adresse an der der Sprung-Befehl selbst steht gespeichert wird - also quasi "springe N Bytes nach vorne/nach hinten". Wenn sich das Ziel im gleichen "modul" befindet muss hier nie etwas angepasst werden, da unter Windows immer nur Module als ganzes "re-based" werden.

Das ganze hat aber nicht wirklich etwas mit single-pass vs. multi-pass zu tun, oder mit Prototypen vs. Type-Libraries bzw. Assemblies mit Type-Information (wie sie von C# oder Java verwendet werden) zu tun.