Standard Portable Library - hat die schonmal jemand benutzt?

[pumuckl]

Dravere schrieb:

Es ist mühsam in der STL, dass durch das neue sortieren von Container oder umstellen usw., der Container jeweils neu erstellt werden muss. Man muss die ganzen Datensätze kopieren, anstatt dass man eine Art von View darauf erstellen kann.

Dafür gibts Umsetzungen in boost, die haben Container mit mehrfachen views (z.B. verschiedene Sortierungsrelationen)

[Bulli]

Dravere schrieb:

Ich halte sowas für ein kleineres Übel und habe auch so meine Zweifel, dass dadurch "poor performance" entstehen. Wenn es Probleme mit Kopien gibt, dann sicher nicht bei einem push_back .

Das ist sicherlich keine falsche Meinung.

[Dravere]

Bulli schrieb:

... wobei es bei diesen wohl eher historisch bedingt ist (alle schon existent, bevor es eine Std-Lib gab).

Mit ziemlicher Sicherheit. Und zum Teil wollen die auch noch uralte Kompiler unterstützen, welche noch keine sinnvolle Standardbibliothek haben. Zum Beispiel wxWidgets.

Bulli schrieb:

Aber es gibt auch genug neue Libs die die Std-Lib meiden.

Das gibt es in jeder Sprache. Es gibt genauso genügend C++ Bibliotheken, welche die Standardbibliothek verwenden. Man muss allerdings auch sehen, dass die Standardbibliothek immer noch relativ jung ist. Die Menschen lernen langsam

pumuckl schrieb:

Dafür gibts Umsetzungen in boost, die haben Container mit mehrfachen views (z.B. verschiedene Sortierungsrelationen)

Ist mir bekannt, benutze ich auch schon. Aber solche Dingen sollten halt in den Standard rein
Boost hat sogar eine Range Umsetzung.

Grüssli

[Shade Of Mine]

Dravere schrieb:

Shade Of Mine schrieb:

Nope, die Kopie ist komplett unnütz.
Das ist auch eins der größten C++ Probleme aktuell. Deshalb komman ja rvalue referenzen

Wieso soll die Kopie unnütz sein? Ein rvalue würde doch das alte Objekt zerstören, bzw. unbrauchbar machen. Was ist, wenn du es noch brauchst? Dann darfst du das Objekt nicht in den std::vector schieben, solange du es noch brauchst? Seltsames Verhalten würde ich das nennen.

Man braucht das Objekt aber quasi nie. Und dann kann man ja immer noch eine Kopie ziehen.

das problem ist ja, dass du in c++ sinnlos viele temp objekte hast die du nie verwendest.

string foo() { return string(..); }
v.push_back(foo())

wieviele ctors und dtors werden hier aufgerufen?
korrekt wäre: 1 ctor und kein dtor. in c++ hat man aber 3 ctors und 2 dtors.
und muss man beten dass der compiler rvo/nrvo anwenden kann...

Kann sein, dass man sowas zum Teil benötigt, aber ich bin oft auch froh, wenn das Objekt in den Container kopiert wird. Allenfalls kann man sich sowas aktuell auch über Zeiger einrichten.

zeiger bedeuten indirektion (lokalität!) und probleme mit resource management.

Ich halte sowas für ein kleineres Übel und habe auch so meine Zweifel, dass dadurch "poor performance" entstehen. Wenn es Probleme mit Kopien gibt, dann sicher nicht bei einem push_back .

doch. das befüllen von containern ist in c++ deutlich langsamer als in java. (von den ganzen anderen copy situationen mal abgesehen).

[Dravere]

Shade Of Mine schrieb:

und muss man beten dass der compiler rvo/nrvo anwenden kann...

Wobei heutzutage die meisten Kompiler dies unterstützen.

Shade Of Mine schrieb:

doch. das befüllen von containern ist in c++ deutlich langsamer als in java. (von den ganzen anderen copy situationen mal abgesehen).

1. Ich wollte aber darauf hinaus, dass es ein schlechtes Beispiel ist, weil es eben deutlich schlimmere Kopieprobleme gibt. Also eben die anderen Situationen, welche du hier alle ausschliesst.
2. Und ob es in C++ wirklich deutlicher langsamer als in Java ist, weiss ich nicht. So ein Testbericht würde ich aber gerne mal sehen. Es ändert meine Meinung dazu aber nicht, push_back wird wahrscheinlich das kleinere Problem sein und eben nicht zu "poor performance" führen.

Grüssli

[Shade Of Mine]

Dravere schrieb:

Shade Of Mine schrieb:

und muss man beten dass der compiler rvo/nrvo anwenden kann...

Wobei heutzutage die meisten Kompiler dies unterstützen.

anwenden können != unterstützen

[maximAL]

Kann mir mal schnell einer zusammen fassen, was mich daran hindert, einfach Containern von Pointern zu benutzen, wenn ich nichts kopieren will?

[theta]

maximAL schrieb:

Kann mir mal schnell einer zusammen fassen, was mich daran hindert, einfach Containern von Pointern zu benutzen, wenn ich nichts kopieren will?

Nichts. Pass einfach auf dass zu jedem new/new[] ein delete/delete[] geschrieben steht.

Simon

[pumuckl]

theta schrieb:

maximAL schrieb:

Kann mir mal schnell einer zusammen fassen, was mich daran hindert, einfach Containern von Pointern zu benutzen, wenn ich nichts kopieren will?

Nichts. Pass einfach auf dass zu jedem new/new[] ein delete/delete[] geschrieben steht.

Simon

Smartpointer beheben das new/delete-Problem. Allerdings wirst du eigene Comparatoren schreiben müssen.

[Shade Of Mine]

maximAL schrieb:

Kann mir mal schnell einer zusammen fassen, was mich daran hindert, einfach Containern von Pointern zu benutzen, wenn ich nichts kopieren will?

Du verlierst Performance durch keine cache lokalitaet und indirekte zugriffe. noch dazu musst du am free store allokieren und nicht am stack.

[tntnet]

Shade Of Mine schrieb:

maximAL schrieb:

Kann mir mal schnell einer zusammen fassen, was mich daran hindert, einfach Containern von Pointern zu benutzen, wenn ich nichts kopieren will?

Du verlierst Performance durch keine cache lokalitaet und indirekte zugriffe. noch dazu musst du am free store allokieren und nicht am stack.

Wenn ich beispielsweise einen std::vector<std::string> definiere, dann verwaltet der std::string intern einen Zeiger auf den Heap und schon ist meine cache lokalität nicht vorhanden. Das entspricht also dem Verhalten von Containern von Zeigern.

Habe ich eine Klasse, die keine Zeiger hat, also so etwas wie PODs, sind diese billig kopierbar und damit gibt es keinen Grund, im Container Zeiger darauf zu halten. Damit habe ich cache Lokalität.

Unter C++ hat man halt die Wahl (oder auch Qual der Wahl).

[theta]

Wenn ich beispielsweise einen std::vectorstd::string definiere, dann verwaltet der std::string intern einen Zeiger auf den Heap und schon ist meine cache lokalität nicht vorhanden. Das entspricht also dem Verhalten von Containern von Zeigern.

Kommt (bei den meisten impl.) auf die länge des Strings an ob Stack oder Heap.

Simon

[Shade Of Mine]

tntnet schrieb:

Wenn ich beispielsweise einen std::vector<std::string> definiere, dann verwaltet der std::string intern einen Zeiger auf den Heap und schon ist meine cache lokalität nicht vorhanden. Das entspricht also dem Verhalten von Containern von Zeigern.

small string optimization zB
aber worum es geht ist dass zB size() ja kein cache miss ist. du also nicht zwangsläufig schlechte cache lokalitaet hast. dass es natürlich vorkommt ist klar.

[Gast]

Den Kritikpunkt mit der "unnötigen" Kopie kann ich nicht nachvollziehen - man kann sich's ja eben in C++ genau aussuchen, ob man lieber Pointer oder Objekte kopiert. Die Container sind für einfache, leicht und korrekt zu kopierende Elemente designed. Wenn std::string das nicht erfüllt, tut man eben keine std::string rein. Wenn man die Container gegen ihr Design verwendet, handelt man sich den Ärger ein und braucht sich nicht beschweren.

In Java ist nichts billiger daran, etwas in einen Container zu tun, man hat nur keine Wahl mehr, was man genau reintut.

Falls ihr auf der Suche nach "pointer-friendly" containern seid, dann bietet sich übrigens boost.ptr_container an.

[Shade Of Mine]

freestore vs stack

c++ 101 eigentlich...

wenn wenigstens ein hinweis auf intrusive container gekommen wäre. aber nur weil man probleme wegdiskutiert lösen sie sich nicht auf.

[Gast]

Shade Of Mine schrieb:

freestore vs stack

c++ 101 eigentlich...

wenn wenigstens ein hinweis auf intrusive container gekommen wäre. aber nur weil man probleme wegdiskutiert lösen sie sich nicht auf.

Was willst du sagen?