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. Im Studium habe ich selbst vectoren usw. implementiert um zu wissen wie es funktioniert. Aber ich wuerde nie auf die Idee kommen einen Container usw. fuer die Entwicklung zu schreiben. Ich mag C++ sehr und habe schon viele Programme geschrieben (nur Forschung oder Hobby) bisher konnte ich mich nie ueber die STL beklagen. Oft schaue ich mir auf youtube Konferenzbeitraege (Going Native etc.) an. Ich verstehe viele Sachen in C++ noch nicht und werde viele Sachen wahrscheinlich auch nie richtig verstehen. Aber ich denke die STL ist wirklich von Leuten geschrieben die C++ wirklich zu 100% verstehen und sie liefert fuer fast alle Arten von Programmen eine sehr gute Performance.

Ich habe nicht in grossen Firmen gearbeitet und ich will es mir nicht anmassen ueber Software zu urteilen an der ich nicht mirgearbeitet habe. Aber wenn ich die Leute im Vorstellungsgespraech so reden hoere habe ich das Gefuehl die STL hat keinen Wert.

Wie ist eure Meinung dazu?

mfg

Wie ist eure Meinung dazu?

Natürlich dass du Recht hast? Boost sollte man vielleicht nicht immer benutzen, aber die STL definitiv.

Du hast im Studium vector implementiert. Dann haste hoffentlich auch gespürt, daß er ein wenig nach Hilfe ruft. Oft braucht man kein push_back, sondern benutzt ihn nur als Array, wozu die Trennung zwischen capacity und size dann? Weil es kein vergleichbares array im Freispeicher gibt. Oft will ich nur ganz kleine Mengen zurückgeben, vielleicht die 2 bis 10 nächsten möglichen Züge, dafür ein new+delete zu bezahlen macht keinen Spaß (neumodischer Kram wir return ohne copy veränderte den Bedarf). Da doch wäre ein vector nett, dem man sagen kann, ob er Freispeicher oder Stack benutzt und der sich wenn man es nicht angibt, eine gescheite Schätzung macht (im Stack-Fall geht push_back nur SIZE mal, aber egal, es klappt und fühlt sich gut an, habe es selber schon benutzt). Wenn man ihn als array verwendet, dann ist es bei PODs oft kriminell doof, daß er seine Elemente erst alle mit 0 initialisiert (neumodischer Kram wie sauschnelle Prozessoren auf lahmem RAM veränderten den Bedarf). Außerdem kann man mit eigenen Klassen auch gewissen Vorgaben erzwingen: Vielleicht will man immer reserve beim Konstruieren erwzingen? Man kann besser Debuggen: Bei Fehlern eigenes ASSERT, was noch im Betatest nach hause telefoniert.

Und was die vielen Bäume und Hashtables angeht...
Da kann man alle möglichen Wünsche haben, vielleicht mal B-Bäume (Cache-Lines ausnutzen), stratifizierte Bäume(paralleler Zugriff), Spreizbäume(Zugriffslokalität ausnutzen), bei Hashtables sieht es ähnlich aus, und wir haben noch kein Wort über Persistenz verloren.

Kurzum, die STL ist gut für den Normalfall, aber wenn man die richtigen Leute hat, ist es gar kein Riesenfehler, sie zu pimpen. Wenn man dann noch der Meinung ist, sort(v.begin(),v.end()) sei eine bekloppte Schreibe für v.sort(), bleibt einem fast nichts anderes mehr übrig. Kann man sich Container vorstellen, die ein v.sort() mit Zerstörung aller bisherigen Iteratoren schneller hinkriegen, als ein sort(v.begin(),v.end()) unter Beibehaltung derselben?

Die STL zu meiden hat aber den Riesen-Nachteil, daß sich die neuen Leute erst in die eigene Bibliothek einarbeiten müssen, während man ein wenig Vertrautheit mit der STL voraussetzen kann. Wenn alle Deine Unternehmen die stl meiden, machen vermutlich die allermeisten einen dicken Fehler, oder Du hast ein echt extravagantes Muster, wo Du Dich bewirbst.

Ich würde mir die Begründung anhören, warum das Unternehmen die stl meidet, und wenn die überzeugend ist, wäre ich lieber dort viel lieber als in einer Standard-Klitsche.

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.

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

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.

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 ...

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.

@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...

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.

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.

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 ...

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.

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.

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.

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

Weitgehend?

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...;)

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.

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: 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

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