Nutzung der STL in Firmen. Ist die STL schlimm?

[sizeoflist]

Als ich das letzte mal mit VS2008 geschaut hatte, war sizeof(std::list) auch relativ groß. Wenn man sich da einen Graph mit 5.000.000 Objekten, von denen jedes eine list enthält, aufbauen will ist glaube ich schon mit den leeren Listen eine ganze Menge Speicher verbraucht worden.

[Nexus]

Hängt natürlich auch stark vom jeweiligen Anwendungsfall in der Firma ab. Wie schon erwähnt, ist die STL für "General-Purpose" Container ideal, nicht selten besser als handgestrickte Lösungen. Man sieht auch teilweise Ablehnung gegenüber dem etwas speziellen Design der STL, weil die Konzepte generischer Programmierung nicht verstanden wurden und Leute sich Vererbungshierarchien eher gewohnt sind. Argumente wie "die STL-Container bieten zu wenig Funktionen an [gemeint sind Memberfunktionen]" sind nicht untypisch. Total lächerlich ist z.B. die Begründung von Irrlicht. Ist zwar schon eine Weile her, aber es sieht nicht so aus, als wäre der Entwickler mittlerweile einsichtig geworden.

Wo die STL definitiv nicht mehr ausreicht, sind spezielle Datenstrukturen wie z.B. Graphen, Matrizen, ... In diesen Gebieten gibts in der Regel aber auch spezialisierte Bibliotheken, die besser optimiert und getestet wurden als eigene Implementierungen. In den Fällen dazwischen können sich Neu-Implementierungen lohnen, wenn man sie tatsächlich mit gewonnenen Features oder Performance rechtfertigen kann.

[Werner Salomon]

halte Dich von diesen Firmen fern.

natürlich ist es kein Problem und auch manchmal notwendig, wenn man einen eigenen Container oder Algorithmus schreibt. Aber ein generelles STL-ist-nix-wir-haben-unseren-eigenen-Kram ist IMHO schlicht Dummheit. Die STL ist Teil des C++-Standards und damit ein Teil von C++. Ich kenne letztendlich nur drei Gründe, die zu so einer Haltung führen
1. was der Bauer nicht kennt, frisst er nicht (ich entschuldige mich bei allen Landwirten)
2. 'not invented here' alias: mein Code ist besser als jeder andere
3. Die Software ist entstanden, als noch keine (zuverlässige) STL verfügbar war

ich lasse nur Punkt 3 als echtes Argument gelten, und das wiederum würde nicht ausschließen, dass man neue Dinge nicht doch mit der C++-Standard-STL erledigt. Auch wenn es dann ein gewisser Stilbruch wäre.
Ganz dumm finde ich noch das Argument im Kontext zu Punkt 2 - "mein/unser Code ist schneller". Und zwar bei jeder(!) eigenen Container-Implementierung - irgendwelche Spezial-Sachen wie oben schon erwähnt mal ausgenommen.
Ja - wenn es wirklich so ist - um wie viel den bitteschön? Wie viele Nanosekunden (pro Benutzereingabe!) werden denn damit eingespart? Und zu welchem Preis wurde dieser (evt. nicht mal messbare) "Vorteil" erkauft?

Solche Firmen (oder Gruppen) mit dieser Haltung sind i.A. lernresistent - weil sie wissen ja alles (besser) - und können sich daher auch schwerlich weiter entwickeln.

Bei all dem oben gesagten meine ich 'normale C++-Anwendungen'. Daneben sind noch Hochsicherheits-Anwendungen denkbar, die wahrscheinlich sogar ihren eigenen Compiler haben und den Binärcode einer statischen Analyse unterziehen. So was ist hier nicht gemeint.

Gruß
Werner

[Mechanics]

Ich hab bei uns im Code mal eine Bubble Sort Implementierung gefunden, die an paar Stellen verwendet wurde. Hat ein Praktikant vor 20 Jahren geschrieben, haben sich paar Leute dann gedacht, cool, wir haben schon eine Hilfsfunktion zum Sortieren, ist bestimmt einheitlich, wenn ich die verwende. Hab das dann alles rausgeschmießen.

[hustbaer]

Werner Salomon schrieb:

3. Die Software ist entstanden, als noch keine (zuverlässige) STL verfügbar war

Wenn man cross-plattform entwickelt und nicht überall ne aktuelle GCC/Clang/MSVC Version verfügbar ist, kann das heute auch noch ein Grund sein.

Ist aber natürlich eher die Ausnahme. Die meisten Firmen betrifft das nicht.

[RHBaum]

Das liegt nicht an der STL sondern an der Inkompetenz in vielen Firmen.

Ich denk mal das zu hart geurteilt

Die meisten STL Konkurrenten sind keine reinen Nachbauten, sondern ham scho Unterschiede.

Meine Spezies verwenden z.b. extrem gern die QT-Container.
Solange es um eine sowieso schon Qt Umgebung handelt und wenn Multithread dann auch gewisse Dinge vermieden werden, die mit der STL aufgrund der Zusagen funktionieren würden, warum nicht ?

Als Folge erhält man meist einfacher zu lesenden Code (zumindest besser lesbar als wenn die auf die STL losgehen).
generell erhaelt man viel simpleren, naiveren Code, wenn man sich auf cow Techniken verlaesst, anstatt selber aufzupassen. Wenn die Randbedingungen passen, warum nicht ...

Ciao ...

[Marthog]

hustbaer schrieb:

Wenn man cross-plattform entwickelt und nicht überall ne aktuelle GCC/Clang/MSVC Version verfügbar ist, kann das heute auch noch ein Grund sein.

Man kann dennoch alte Funktionalitäten verwenden oder als Alternative die Klassen aus boost verwenden.

[hustbaer]

@Marthog
Nicht wenn man mit nem schrottigen (non-standard) C++ Compiler inklusive schrottiger (fehlerhafter und/oder langsamer) Standard-Library Implementierung arbeiten muss
Denk an Visual C++ 4.x & Co.

@RHBaum
Und ich denke mal das stimmt genau so.

RHBaum schrieb:

Als Folge erhält man meist einfacher zu lesenden Code (zumindest besser lesbar als wenn die auf die STL losgehen).
generell erhaelt man viel simpleren, naiveren Code, wenn man sich auf cow Techniken verlaesst, anstatt selber aufzupassen. Wenn die Randbedingungen passen, warum nicht ...

Versteh ich nicht. Simpler zu lesen ist grundsätzlich mal relativ. Hängt stark davon ab was man kennt/gewohnt ist. Und da die Standard-Library halt Standard ist... sollte man die mMn. auch verwenden. Weil halt jeder Programmierer "seine" Standard-Library kennen sollte. Qt oder irgend ein anderes Framework kann ich aber nicht von jedem erwarten.

Und was der 2. Satz bedeuten soll versteh ich gleich gar nicht. Kopierst du denn andauernd Container durch die Gegend, oder wo verlässt du dich auf COW, wo es mit der STL nötig wäre "selbst aufzupassen"?
MMn. ist mit C++11 fast alles weggefallen wo man gerne eine Kuh sehen würde...

[Mechanics]

hustbaer schrieb:

MMn. ist mit C++11 fast alles weggefallen wo man gerne eine Kuh sehen würde...

Naja, nicht ganz (abgesehen davon werden zumindest wir in absehbarer Zeit kein C++11 verwenden). Es gibt z.B. Fälle, wo man Container wirklich kopieren würde. Es gibt irgendwo eine Liste mit irgendwas, die wird an den Konstruktor einer anderen Klasse übergeben, die sich die Liste in einer Member Variable speichert. z.B. ein Runnable, oder irgendein GUI Element oder sonst was. Da kann man die Liste oft nicht moven.

[hustbaer]

Und die Qt Container machen das? Also COW?

EDIT: OK, ja, machen sie.

Implicit sharing has another consequence on STL-style iterators: You must not take a copy of a container while non-const iterators are active on that container. Java-style iterators don't suffer from that limitation.

ARGH.
Also dann lieber Kopien.
Solche "das darfst du dann aber nicht machen" Sachen mag ich gar nicht.

[RHBaum]

Kopierst du denn andauernd Container durch die Gegend, oder wo verlässt du dich auf COW, wo es mit der STL nötig wäre "selbst aufzupassen"?

Ja klar wenn man sich auf COW verlaesst, muss man sich keine sorgen um die Kopien machen ... damit kann man viel einfacheren Code schreiben.

berühmtes Besipiel:

QString strCSV = "1834;28540;2345;2384;293045;12034;23095;92582";

QStringList splitList = strCSV.split(';');

jetzt programmier das mal mit der STL nach ....
geht sicherlich, sieht aber nicht ganz so easy aus oder ?

und dann, versuch mal das Splitten in eine komfortable funktion zu packen, man braucht das ja öfter, und garantiere dabei das das performance technisch keine unnötigen kopien macht. ohne precompiler Macros !
Du wirst keine Lösung finden die sooo naiv, unschuldig wie die obige mit COW aussieht.
Ok, glaub mit C11 + move semantic geht sicher doch was ^^
Aber ich muss hier VS 2005 kompatibel bleiben (bin froh das ich nicht noch VS 6.0 unterstützen muss)

Oder anderes besipiel:

Ziemlich oft gesehen:

typedef QMap<QString,QString> DictionaryT; /// klar mit Hashmap geht noch bissi mehr, aber so schlecht iss das nicht

Gute Idee:
STL Verwenden !
Schlechte Idee:

typedef std::map<std::string,std::string> DictionaryT;

Und sich dann wundern, warum sich das arbeiten mit dem PC anfühlt, als wär die Handbremse angezogen !
Sowas macht keiner ?
Such mal die Ct raus mit dem performance vergleichstest zwischen java c# VB und c++ . Iss scho paar Jahre her ^^

Mit der Zeit gewöhnt man sich an die STL syntax, klar ... wenn man sie "häufiger" benutzt. Dann kriegt man nen Gefühl fuer die STL. Für Bibliotheksentwickler, Multithreading Themen ... etc. unabdingbar.

Aber wir haben z.b. Kollegen, die machen z.b. nur GUI's. Wenn ich denen mit der STL komme ... aua. Sind das keine Programmierer ?
Klar, QT Programmierung allgemein ist styletechnisch mehr Java als C++ , aber trotzdem haben die auch ihre daseinsberechtigung Und die koennen Java und GUI Design sicher besser als ich ^^

Ciao ...

[Shade Of Mine]

hustbaer schrieb:

Versteh ich nicht. Simpler zu lesen ist grundsätzlich mal relativ. Hängt stark davon ab was man kennt/gewohnt ist. Und da die Standard-Library halt Standard ist... sollte man die mMn. auch verwenden. Weil halt jeder Programmierer "seine" Standard-Library kennen sollte. Qt oder irgend ein anderes Framework kann ich aber nicht von jedem erwarten.

Wenn man aber eine Qt App entwickelt, dann kann man das sehr wohl erwarten und dann passen die Qt Container deutlich besser in die App als die STL.

[Nexus]

RHBaum: std::string ist oftmals wirklich nicht ideal. Auch ist es äusserst unglücklich, dass wir für Algorithmen wie split Boost brauchen und sowas nicht in der Standardbibliothek haben.

Qt (nicht QT) ist aber auch ein sehr bekanntes Framework. In dessen Kontext auch Qt-Container zu verwenden finde ich ok (man hat ja kaum eine andere Wahl), in diesem Thread gehts aber eher um selbstgebastelte Lösungen und das Not-Invented-Here-Syndrom.

Was unnötige Kopien angeht, die sind mit C++11 Move-Semantik weitgehend beseitigt. Je nach Anwendungsfall kann man auch mit Techniken wie Expression Templates recht tricksen.

[Columbo]

Wenn man aber eine Qt App entwickelt, dann kann man das sehr wohl erwarten und dann passen die Qt Container deutlich besser in die App als die STL.

Da hast du voellig Recht. Daher auch meine Nachfrage: Wenn man die Qt-Container einfach ohne praktischen Grund verwendet (einer waere zum Beispiel dass Qt-GUI diese benoetigt), einfach weil man sie besser kennt, dann ist das sehr merkwuerdig.

@hustbaer: Je mehr ich ueber deine Arbeit hoere, desto mehr tust du mir Leid. Ist furchtbar.

[Columbo]

die sind mit C++11 Move-Semantik weitgehend beseitigt.

Weitgehend?

[wuselwicht]

STLOderWas schrieb:

Hallo,

ich hatte in letzter Zeit mehrere Vorstellungsgespraeche bei Softwarefirmen (bunt gemixt, Spielefirmen, etc.).

In den Gesprachen habe ich immer gesagt ich versuche wo es nur geht die STL und Boost zu benutzen. Fast jedes mal bekam ich die Antwort, "STL/Boost benutzen wir nicht, wir haben unsere eigenen Container usw.".

Wenn ich das hoere laeuft es mir immer kalt den Rucken runter.

Wie ist eure Meinung dazu?

Ich würde mich fragen, warum es in den Unternehmen andersläuft, mir die Programmierpraktiken/Bibs genauer anschauen wollen. Mit genauere Kenntnis der Zusammenhänge fiele das Argumentieren für oder gegen bestimmte Arbeitsweisen leichter.
Da ich auch (wirtschaftlich) rechnen kann, könnte ich Vor- und Nachteile direkt vorrechnen.
(Außerdem, steh ich auf Optimieren, Refactoring und so *sabber* wenn es zufällig irgendwas schluderig zusammengefrickeltes gibt, dann nichts wie hin zum Grusel-Gedöns...;)

[Nexus]

Arcoth schrieb:

die sind mit C++11 Move-Semantik weitgehend beseitigt.

Weitgehend?

Ja, Move-Semantik alleine löst nicht alle Probleme.

std::string t = "text";
std::string r = t + " und " + "mehr " + t;

Wie viele temporäre Objekte hast du hier? Und wie viele sind tatsächlich nötig? QString scheint diesbezüglich intelligenter zu sein.

[ich bins]

Nexus schrieb:

Arcoth schrieb:

die sind mit C++11 Move-Semantik weitgehend beseitigt.

Weitgehend?

Ja, Move-Semantik alleine löst nicht alle Probleme.

std::string t = "text";
std::string r = t + " und " + "mehr " + t;

Wie viele temporäre Objekte hast du hier? Und wie viele sind tatsächlich nötig? QString scheint diesbezüglich intelligenter zu sein.

Könntest Du das Problem so erläutern, dass auch nicht-C++-Experten das verstehen? Da wäre ich Dir dankbar.

[hustbaer]

Arcoth schrieb:

@hustbaer: Je mehr ich ueber deine Arbeit hoere, desto mehr tust du mir Leid. Ist furchtbar.

Was ist furchtbar?
Dass wir kein Qt verwenden?
OMFG... ja, ganz schlimm

[Nexus]

ich bins schrieb:

Könntest Du das Problem so erläutern, dass auch nicht-C++-Experten das verstehen? Da wäre ich Dir dankbar.

Das Problem hierbei ist, dass eine klassische Implementierung für jeden Aufruf von operator+ ein neues temporäres Objekt erzeugt. Die schrittweise Auswertung könnte also so aussehen:

r = a + b + c + d;
r =   ab  + c + d;
r =      abc  + d;
r =       abcd;

Dadurch wird der String in a und b z.B. 3 Mal kopiert (er kommt nämlich in ab , abc und abcd vor), der in c 2 Mal ( abc , abcd ), etc. Bei der letzten Zuweisung kann der Move-Zuweisungsoperator benutzt werden.

Wenn du hingegen

r = a;
r += b;
r += c;
r += d;

schreibst, arbeitest du direkt in-place und kannst die temporären Wegwerfobjekte vermeiden. Das ganze ist immer noch nicht optimal, da der std::string unter Umständen reallokiert werden muss, obwohl die Grösse aller beteiligten Objekte im Voraus addiert werden könnte.

Eine mögliche Lösung des Problems stellen Expression Templates dar; diese auf Lazy Evaluation (später Auswertung) basierende Technik sorgt dafür, dass zwischenzeitliche Wegwerf-Objekte vermieden werden. operator+ würde dann keinen std::string zurückgeben, sondern ein Proxy-Objekt, welches zu std::string konvertierbar ist -- bei der Konvertierung wird der String zusammengesetzt. Zu diesem Zeitpunkt sind die notwendigen Informationen wie gesamte Grösse vorhanden und können zur Optimierung ausgenutzt werden.

Expression Templates führen allerdings zu Problemen mit Templates und Typinferenz, da das Resultat selbst kein String ist. Folgender Code würde also zu unerwarteten Ergebnissen führen:

template <typename T>
void fn(const T& t);

auto r = a + b + c + d; // r ist kein std::string
fn(a + b + c + d);      // T ebenfalls nicht