?
Noch als Korrektur:
IIRC gab es unter Win95 2GB Adreßraum für alle Prozesse. Seit 98 sind das 2GB pro Prozeß, unter NT-basierten Systemen sind auch 3GB möglich.
globale Variablen:
Außer daß sie heutzutage das sind was goto in den 80'ern war: so eine art bitterböser Klassenfeind, gibt es effektive Nachteile. Grob kann man sagen: Für EXE ok, für Library meist tabu.
* Hauptgrund: Multithreading:
Da alle Threads sich eine Instanz teilen, muß der Zugriff serialisiert werden. Bibliotheken die das nicht tun, können i.a. nicht von mehreren Threads bzw. reentrant aufgerufen werden, und fallen damit häufig aus.
Die C-Standardbibliotheken, die recht viel mit statischen Buffern oder Variablen arbeiten, verwenden eine Instanz pro Thread. Das can man zwar auf den meisten Systemen auch mit seinen statischen Variablen machen, ist aber nicht portabl. Und die "bequeme" Windows-Lösung ( __declspec(thread) ) funktioniert leider nicht bei dynamisch geladenen DLL's.
* Global Namespace Pollution
Der Linker kann globale Symbole mit gleichem Namen nicht trennen, auch wenn sie aus zwei verschiedenen Lib's stammen. Hier helfen aber C++ namespaces.
* EVENTUELL: Unsauberer Programmierstil
Die Verwendung vieler globaler Variablen legen den Verdacht auf einen unsauberen Stil nahe. Aber wie so oft sind die globalen Variablen nur ein Indikator und nicht die Ursache. Das eigentliche Problem ist normalerweise ein unsauberer oder zugemüllter Zustandsraum.
Deswegen kriegt jede MFC-Anwendung von mir sofort ein "extern CXyzApp theApp" verpaßt, ohne das mein Karma leidet.
