Nutzung der STL in Firmen. Ist die STL schlimm?

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

[Werner Salomon]

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

ganz auf die Variable

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

zu verzichten und gleich splitList aus der Datei zu lesen.

[Nexus]

dot schrieb:

Finde ich nicht. split() lässt sich, wie oben angeführt, aus Prinzip nicht effizient implementieren

Warum nicht? Wenn du den Kompromiss eingehen kannst, dass nicht jeder Teilstring seinen eigenen Speicher braucht und du nur lesend auf die Teile zugreifst, kannst du durchaus optimieren. Nämlich indem du "leichte" Strings benutzt (Ranges mit Anfangs- und Endzeiger). Du kannst das auch mit Iteration kombinieren, ähnlich wie std::string::find() mit einem Anfangs-Index bzw. -Iterator.

dot schrieb:

Und das lässt sich mit Hilfe von streams wesentlich besser umsetzen...

Wie viele Zeilen Code brauchst du, um das gleiche mit Streams zu erreichen? Ausserdem sind Streams nicht gerade billig. Du brauchst mindestens einen Puffer für den Stream und einen für den String, in den du extrahierst -- zusätzlich zum String, aus dem du ausliest. Wenn du hingegen nur iterieren würdest, kämst du gänzlich ohne dynamische Speicheranforderung aus.

Wenn du natürlich direkt aus der Datei liest, siehts wieder anders aus. Ich bin hier davon ausgegangen, dass ein String vorliegt.

[dot]

Werner Salomon schrieb:

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

ganz auf die Variable

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

zu verzichten und gleich splitList aus der Datei zu lesen.

Das stimmt natürlich, setzt aber voraus, dass man eine Datei hat...

knivil schrieb:

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.

Es ist voraussichtlich gültiges C++14, MSVC kann's schon... :p

Nexus schrieb:

dot schrieb:

Finde ich nicht. split() lässt sich, wie oben angeführt, aus Prinzip nicht effizient implementieren

Warum nicht? Wenn du den Kompromiss eingehen kannst, dass nicht jeder Teilstring seinen eigenen Speicher braucht und du nur lesend auf die Teile zugreifst, kannst du durchaus optimieren. Nämlich indem du "leichte" Strings benutzt (Ranges mit Anfangs- und Endzeiger). Du kannst das auch mit Iteration kombinieren, ähnlich wie std::string::find() mit einem Anfangs-Index bzw. -Iterator.

Das ist auch nicht optimal, da du den String effektiv öfter als genau einmal durchläufst, da du immer das Ende vom nächsten Teil suchen musst, bevor du das Intervall zurückgeben kannst, welches der Benutzercode in weiterer Folge wohl wieder durchlaufen wird. Außerdem musst du weiterhin irgendwie eine Liste von Intervallen zurückgeben, was zuallermindest eine dynamische Speicheranforderung bedeutet...

Nexus schrieb:

dot schrieb:

Und das lässt sich mit Hilfe von streams wesentlich besser umsetzen...

Wie viele Zeilen Code brauchst du, um das gleiche mit Streams zu erreichen?

Siehe z.B. oben.

Nexus schrieb:

Ausserdem sind Streams nicht gerade billig. Du brauchst mindestens einen Puffer für den Stream und einen für den String, in den du extrahierst -- zusätzlich zum String, aus dem du ausliest.

Custom streambuf

[hustbaer]

Nexus schrieb:

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.

Eigentlich egal wie viele Temps es hier gibt. Das Beispiel hier lässt sich relativ gut mit Move optimieren. COW dagegen bringt hier mMn. nichts bzw. nicht viel.

Das grundlegende Problem ist aber eher dass C++ keine Unterscheidung zwischen Strings und String-Builder macht.
Und der String daher nie wissen kann ob er auf schnelle Änderungen optimieren soll (=deutlich zu viel Speicher anfordern wie es ein String-Builder machen würde) oder auf Speicherverbrauch.
Weil er nie weiss wann er "fertig" ist.
Und das lässt sich mit COW genau so wenig lösen wie ohne COW.

Davon abgesehen... ich hab nichts gegen COW - wenns angebracht und sinnvoll umgesetzt ist finde ich es sogar sehr toll.
Ich hab' nur was gegen COW-um-jeden-Preis.