Softwareentwicklung in C++ - ASC

494 16. Die C++ Standard Library
beschließen die Entwickler, dass es nun wirklich an der Zeit wäre, eine allgemeingültige
Version zu schreiben, die auch den anderen Leuten im Team
oder in der ganzen Firma zur Verfügung stehen soll. Auf diese Art kam und
kommt es ständig dazu, dass Dinge, die zum Teil bereits seit der tiefsten
Steinzeit der Softwareentwicklung bekannt und gelöst sind, wieder und wieder
von neuem geschrieben werden. Das bedeutet auch, dass gleichermaßen
immer und immer wieder dieselben Fehler gemacht werden und unter großem
Arbeits- und Zeitaufwand korrigiert werden müssen. Teilweise Schuld an diesem
Phänomen hat auch das sogenannte not invented here Syndrom: “Diese
Implementation kann bei meinem Problem nicht gut funktionieren, weil die
Entwickler dies und das nicht bedacht haben / anders gemacht haben / etc.”
Dass solche Kritik nicht so selten auch ihre Berechtigung hat, soll hier gar
nicht in Frage gestellt werden.
Die Entwickler der STL hatten also folgende Anforderungen zu erfüllen,
um die Library auch wirklich für einen möglichst breiten Anwenderkreis einsetzbar
zu machen:
• Die STL soll allgemein, verständlich und sinnvoll genug gehalten sein, dass
sie für Einsteiger und erfahrene Entwickler gleichermaßen einsetzbar ist.
• Die STL soll nicht nur leicht und sinnvoll bei der Entwicklung von Applikationen
einzusetzen sein, sondern sie soll auch einfach und sinnvoll als
Basis-Library für andere Library-Entwicklungen dienen können.
• Die allgemeinen Implementationen in der STL müssen effizient genug sein,
dass sie gute Alternativen zu speziellen, sehr problembezogenen Implementationen
darstellen.
• Alle Algorithmen, die in der STL Anwendung finden, sollen entweder
Policy-frei sein, oder eine Policy als Argument nehmen. Das bedeutet, dass
es z.B. keinen Sortieralgorithmus in der STL geben darf, der auf Gedeih
und Verderb aufsteigend sortiert und auch zwangsweise die Implementation
der > < und = Operatoren von den einzelnen Elementen erwartet. Es
kann ja auch sein, dass man z.B. absteigend sortieren will und dass man eine
eigene Komparatorfunktion zum Vergleich von Elementen bereitstellen
will. Dies muss dann über entsprechende selbst implementierbare Policies
einstellbar sein.
• Alle Teile der STL müssen so designed sein, dass sie immer nur genau eine
einzige Aufgabe erfüllen, diese aber so gut wie möglich. Niemals darf eine
Komponente zwei miteinander gekoppelte Rollen erfüllen, denn dies geht
erstens zu Lasten der Allgemeinheit und zweitens erlangt man durch explizites
Verknüpfen zweier spezialisierter Komponenten üblicherweise eine
bessere Lösung.
• Komponenten der STL müssen sicher in ihrer Verwendung sein. Das bedeutet,
dass es nicht vorkommen darf, dass man besondere Interna einer
Komponente kennen muss, um mit ihr sinnvoll arbeiten zu können und
z.B. kein Speicherloch zu verursachen.
• Komponenten der STL müssen typsicher sein.