Nutzung der STL in Firmen. Ist die STL schlimm?

[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

[dot]

RHBaum schrieb:

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.

http://www.gotw.ca/publications/optimizations.htm

Keine aktuelle std::string Implementierung wird COW verwenden, da dies spätestens seit C++11 afaik nichtmehr erlaubt ist. MSVC z.B. verwendet aus guten Gründen schon wesentlich länger kein COW mehr (stattdessen small string optimization)...

RHBaum schrieb:

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.

Die einfache und direkte Lösung wäre wohl über std::getline(). Das erzeugt aber Kopien. Gänzlich ohne Kopien wird's tatsächlich schwierig. Wenn du mich fragst, übersiehst du hier aber sowieso etwas ganz grundlegendes, wenn du das effizient haben willst: Der Grund, wieso du hier splittest, wird wohl sein, dass du über die einzelnen Komponenten iterieren willst. Wofür also überhaupt erst eine Liste machen (was hilft dir COW, wenn du dann erst wieder für jeden String ein Listenelement allokierst)? Die effiziente Lösung wäre hier wohl, direkt über den Originalstring zu iterieren (auch gleich verpackt in einer netten Funktion):

#include <algorithm>
#include <iterator>
#include <string>
#include <vector>
#include <iostream>

namespace csv
{
	const std::locale& locale()
	{
		struct csv_facet : std::ctype<char>
		{
			static const mask* get_table()
			{
				static std::vector<mask> v(classic_table(), classic_table() + table_size);
				v[';'] |= space;
				return &v[0];
			}

			csv_facet(std::size_t refs = 0)
				: ctype(get_table(), false, refs)
			{
			}
		};

		static const std::locale csv_loc(std::locale(), new csv_facet);

		return csv_loc;
	}

	template <typename T, typename F>
	void iterate_line(std::string str, F f)
	{
		struct memory_streambuf : public std::streambuf
		{
			memory_streambuf(char* begin, char* end)
			{
				setg(begin, begin, end);
			}
		};

		memory_streambuf buffer(&str[0], &str[0] + str.length());
		std::istream stream(&buffer);
		stream.imbue(locale());

		for (auto n = std::istream_iterator<T>(stream); n != std::istream_iterator<T>(); ++n)
		{
			f(*n);
		}
	}
}

int main()
{
	csv::iterate_line<int>("1834;28540;2345;2384;293045;12034;23095;92582", [](auto n){
		std::cout << n << '\n';
	});

	return 0;
}

Hier wird absolut nichts kopiert und so im Vorbeigehen werden die Substrings auch noch gleich als int geparsed...

RHBaum schrieb:

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 ?

Huch!? was ist das Problem hier? Sowohl std::map als auch QMap basieren auf einem Suchbaum!? Im Falle der STL könnte man einfach std::unordered_map<std::string, std::string> verwenden und schon hat man eine Hashtable...

Nexus schrieb:

Auch ist es äusserst unglücklich, dass wir für Algorithmen wie split Boost brauchen und sowas nicht in der Standardbibliothek haben.

Finde ich nicht. split() lässt sich, wie oben angeführt, aus Prinzip nicht effizient implementieren und ist auch völlig unnötig, da man in der Regel eigentlich keine Liste von Komponenten braucht, sondern lediglich über diese iterieren will. Und das lässt sich mit Hilfe von streams wesentlich besser umsetzen...

hustbaer schrieb:

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

Ich fänds sogar eher furchtbar, wenn ich Qt verwenden müsste...

Nexus schrieb:

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.

Oder man verwendet einfach std::ostringstream...

[knivil]

Die effiziente Lösung wäre hier wohl ...

Keine Streams zu verwenden.

[](auto n){ 
     });

Ist das gueltiges C++11. Wenn nein, dann biste im Falschen Forum.