STL oder MFC - das ist hier die Frage

Veröffentlicht: 18. Nov 2001 | Aktualisiert: 19. Jun 2004

Von Paul DiLascia

In welche Container sollte man seine Daten packen? Die STL bietet neben der Plattformunabhängigkeit raffinierte Funktionen, ist aber nicht ganz leicht einzusetzen. Wir zeigen Ihnen hier Überlegungen zu den Vor- und Nachteilen und der Übertragung von MFC-Code auf die STL.

Auf dieser Seite

 Frage
 Antwort

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Frage

Ich habe schon öfters von der STL gelesen (Standard Template Library). Sollte ich meine Anwendung mit der STL oder mit der MFC entwickeln? Ich würde die Bibliothek für Strings, Vektoren und derlei Dinge verwenden. Welche Vorteile bietet die STL gegenüber der MFC?

Antwort

Die Antwort auf eine "was soll ich nehmen?"-Frage ist eigentlich immer dieselbe: Es hängt davon ab, was Sie tun möchten, welche Anwendung zu entwickeln ist und wie es um Ihre Kenntnisse steht. Der letzte Punkt ist nicht zu unterschätzen. Wenn Sie sich an anspruchsvolle Aufgaben wagen, ist es immer am Besten, zu dem Werkzeug zu greifen, das man auch am Besten versteht. Wenn Sie mit Text hantieren müssen und die MFC kennen, drängt sich CString geradezu auf. Wenn Sie die STL beherrschen, greifen Sie statt dessen zu string. Löst man sich einmal etwas von der täglichen Umklammerung durch die Lieblingswerkzeuge, spielt es eigentlich keine Rolle, was Sie benutzen. Ein String ist so gut wie der andere, eine Liste so gut wie die andere. Allerdings können sich bestimmte Situationen ergeben, in denen das eine oder das andere System besser funktioniert. In meinem RECYCLE-Programm habe ich zum Beispiel die STL eingesetzt. Warum?

Meine erste RECYCLE-Version implementierte ich als Konsolenanwendung mit der MFC. Aus einem einzigen Grund - ich hatte mit der STL bereits Konsolenanwendungen geschrieben. Aber nach einer gründlichen Durchsicht des Codes (das sollte man durchaus häufiger tun) wurde mir klar, dass ich von der MFC eigentlich nur CString und CStringList brauchte. Bei der Untersuchung der Kommandozeilenargumente stellt RECYCLE eine Liste mit den CString-Namen der zu löschenden Dateien zusammen. Was für eine Verschwendung! Die ganze große MFC nur für Strings und Listen. CStringList schleppt die afxcoll.obj ins Programm ein, CString strcore.obj und AfxWinInit besteht natürlich auf allen erforderlichen Initialisierungsmodulen. Man macht sich keine Vorstellung davon, was alles zur MFC gehört, bis man einmal die MAP-Dateien untersucht. Auch ohne MAP-Datei war mir ziemlich schnell klar, das RECYCLE eher ein perfekter Kandidat für die STL ist.

Zur Umstellung auf die STL und zur Entfernung aller MFC-Spuren brauchte ich nur ein paar Zeilen zu ändern. Zuerst musste ich natürlich die Dateien <string> und <list> einbinden. Mit einem typedef erleichterte ich mir dann die Arbeit:

// Stringliste 
typedef list<string> CStringList;

Nur der Name ist derselbe wie in der MFC. Die Schnittstelle ist völlig anders. Insbesondere benutzt die STL keine POSITIONs, sondern Iteratoren:

CStringList files; // Liste der Dateinamen 
... 
CStringList::iterator i; 
for (i=files.begin(); i!=files.end(); i++) { 
... 
}

Ganz unter uns gesagt - ich kann mir die STL-Iteratoren einfacher merken als die POSITIONs von der MFC. Aus irgendeinem Grund behalte ich einfach nicht, wie die POSITIONs genau arbeiten. Und ich ertappe mich ständig dabei, wie ich in den Handbüchern herumwühle. Die begin/end-Syntax samt i++ geht dagegen praktisch ohne gedankliche Anstrengung von der Hand. Andererseits wünschte ich mir in der STL eine Konvertierungsfunktion auf LPCTSTR, wie es sie in

CString gibt. 
CString s;        // MFC 
LPCTSTR pstr = s; // ruft "CString::operator LPCTSTR() const;" auf

Die Konvertierungsfunktion der MFC ist toll. Dank ihrer Hilfe können Sie überall dort ein CString benutzen, wo Sie einen Zeiger auf eine C-Zeichenkette benutzen dürfen. Damit werden zum Beispiel Formulierungen wie

CString s = "Was auch immer"; 
MyFunc(s); // MyFunc erwartet ein LPCTSTR 
möglich, wogegen Sie für die STL explizit string::c_str aufrufen müssen: 
string s; 
MyFunc(s.c_str());

Vielleicht erschienen solche Konvertierungsfunktionen den STL-Designern als eine Art Vernebelung des Geschehens. Das mag wohl richtig sein, kann mich aber angesichts der Eigenheiten der STL nicht so recht überzeugen. Was den generierten Code anbetrifft, spielt das aber keine Rolle. Es geht in diesem Punkt nur um die Bequemlichkeit beim Schreiben.

Der auf den ersten Blick wesentlich wichtigere Grund, der für die STL spricht, ist natürlich die Portabilität. Die STL gehört zum Standard-C++, so wie printf, tolower und strcpy formal zu C gehören. Mir persönlich scheint das Portabilitätsargument aber stets ein wenig flügellahm zu sein, denn die meisten Programme sind sowieso hochgradig plattformabhängig. Auf welchem anderen Betriebssystem gibt es zum Beispiel eine Funktion SHFileOperation? Trotzdem kann es moralisch erhebend sein, die Plattformabhängigkeiten möglichst an einem Ort zusammenzufassen. Und die STL kann Ihnen dabei helfen. Jeder Compiler, der mit der ANSI-Konformität protzt, muss die STL anbieten. Die "Unterstützung" allerdings glänzt nicht immer so wie die Werbeprospekte. So scheint man die STL bei Microsoft zum Beispiel eher für einen Klotz am Bein zu halten und nicht für eine "coole Technologie", auf die man sich stürzen sollte. Man erkennt es an der erstaunlich spärlichen und gelegentlich inkorrekten Dokumentation. In manchen Fällen reicht die Dokumentation auch nicht weiter als der Quelltext.

Andererseits und um fair zu bleiben, die STL ist tatsächlich eine Meditationsübung in kryptischer Ausdrucksweise, mit ihren Partitionen und Generatoren und assoziativen Behältern. Während Template-Code sowieso immer einen erstaunlichen Anblick bietet (sehen Sie sich nur die ATL an!), ist die STL ein ernstzunehmender Anwärter auf den Unlesbarkeitspreis des Jahrhunderts. Aber Unix-Leute wissen ja angeblich, was sie tun. Und wenn Sie sich mit der seltsamen Terminologie der STL arrangieren können, mit unerwarteten Funktionsnamen oder mit absolut leerzeichenfeindlichem Code, dann passt wohl irgendwann plötzlich alles wunderbar zusammen. Auf einmal mögen Sie die STL sogar und entdecken, wie leicht und erstaunlich leistungsfähig sie sein kann. Die STL folgt der Unix-Tradition von Systemen wie SED, AWK und Emacs - schwer zu lernen, aber sehr leistungsfähig und nach der Einarbeitungszeit leicht zu benutzen (Vielleicht sollte ich an dieser Stelle anmerken, dass ich mir den Emacs kaum abgewöhnen kann.). Wenn Sie eine gewisse Exotik mögen, dann versuchen Sie's mit der STL!

Wo erfährt man mehr? Es gibt eine ganze Reihe von entsprechenden Plätzen im Web. Suchen Sie einfach nach der "Standard Template Library". Zu den beliebtesten Websites gehört http://www.sgi.com/Technology/STL/index.html. Dort finden Sie eine verständliche Dokumentation und eine FAQ-Seite. Viel Spass beim Programmieren!