011
05.07.2010, 22:55 Uhr
0xdeadbeef
Gott (Operator)
|
Naja, es ist schon ein elendes Gefummel und performancetechnisch suboptimal, ständig zwischen zwei verschiedenen Bibliotheken, die genau das gleiche machen, vermitteln zu müssen. Sowohl Qt als auch MFC als auch wx definieren ja Klassen, die die Standardbibliothek in ziemlich genau gleicher Form schon beinhaltet.
Das hat halt historische Gründe - als diese Toolkits ursprünglich entwickelt wurden, gab es noch keinen C++-Standard und dementsprechend auch keine Standardbibliothek. Im Fall von Qt geht die Spracherweiterung wohl auch darauf zurück, dass zu der Zeit gängige Compiler mit Templates nicht so umgehen konnten, wie es heute der Fall ist, und das Feld der Template-Metaprogrammierung noch völlig unerforscht war. Dinge wie libsigc++ waren zu der Zeit überhaupt noch nicht möglich, selbst wenn jemand auf die Idee gekommen wäre.
Allerdings gibt es Fälle, in denen Toolkit-Klassen annähernd aber nicht genau das Gleiche machen wie entsprechende Standardklassen. Beispielsweise beinhaltet glibmm eine Klasse Glib::ustring, die UTF-8 kodiert; das wird die C++-Standardbibliothek erst mit C++0x können. Das hat zwar etwas unschönes, aber in der Not frisst der Teufel doppelte Codehaltung.
Allerdings bin ich der Ansicht, dass man diese Altlasten zwischenzeitlich mal hätte aufräumen können. In einem major release muss man keine vollständige Sourcecode-Kompatibilität bieten. -- Einfachheit ist Voraussetzung für Zuverlässigkeit. -- Edsger Wybe Dijkstra Dieser Post wurde am 05.07.2010 um 22:57 Uhr von 0xdeadbeef editiert. |