Standard Portable Library - hat die schonmal jemand benutzt?

[Bulli]

Seit wann ist denn die STL standadisiert??? Die STL ist im Standard überhaupt nicht existent. Die STL ist verändert (und somit inkomptabil) in den Standard eingeflossen, nicht mehr und nicht weniger.

[pumuckl]

Ich bin mal davon ausgegangen dass der OP nicht die 80er/90er Jahre STL von HP meinte sondern deren aktuellen Abkömmling, den Container/Stream/Algorithmen-Teil der Standardbibliothek, der sehr wohl standardisiert ist. Dass die Benennung der Standardbibliothek als STL ebenso häufig wie inkorrekt ist, ist mir bekannt, aber irgendwann resigniert man eben...

[STL]

Map, list, vector, for_each, make_pair, iteratoren und all das?

[VuuRWerK]

Ich hab auch mal reingeschaut und muss sagen das einzige was diese Lib versucht ist eine Java-ähnliche API in C++ zu implementieren, aber das mit roher Gewalt. Da wird wirklich für alles ein Zeiger erzeugt, sogar auf Strings ... (Daher auch der Unfug mit der Exception als Zeiger, denn man muss eben mit gewalt throw new ... schreiben, wird in Java ja auch so gemacht ...)
Zudem erinnert die ganze Umsetzung daran wie es in Java gemacht wurde. Ich find diese Lib mehr als unnötig und großer Unfug. Mit der STL, Boost und gelegentlich einem c-header hat man mehr Spaß und kommt wesentlich sicherer ins Ziel

Gut Schuß
VuuRWerK

[Dravere]

Ihr geht auf die Website zum Projekt und findet das hier:

One of the motivations behind this library is the poor design of the STL. Although STL is theoretically optimally designed, in practice it has a number of failings.
• Poor performance due to obsessive use of copy constructors.
• Semantics that are incompatible with C/C++, such as weird operator overloading, manipulators, functors, etc.
• Nonstandard – the STL approach has not been adopted by the broader industry. Instead, the Java class library has become the baseline against which other frameworks are measured.

Damit ist doch alles gesagt. Ein Java Programmierer probiert in C++ Java zu programmieren

Die STL, bzw. die Standardbibliothek, hat Fehler, aber ganz sicher nicht diese.
- Performance Verlust wegen Copy Konstruktor? LOL?
- Inkompatibel zu C/C++? Noch mehr LOL?
- Kein Standard, nicht aktzeptiert von der Industrie, Java ist übermächtig ... klaaaar

Grüssli

[Bulli]

Wenn man was anderes will, dann vielleicht mal www.pocoproject.org anschauen.

[Bulli]

Dravere schrieb:

• Poor performance due to obsessive use of copy constructors.

Ganz so unrecht haben die ja nicht. Es ist tatsächlich ein Flaschenhals. Z.B. wenn ich einem Container ein Value-Objekt einfügen will, muß dieses kopiert werden. (bei einem Pointer ist das natürlich egal, aber nicht bei Values)
Bsp.:

vector<string> vec;

string s("Test");
vec.push_back(s);   // s wird kopiert

Deshalb wird in C++0x ein &&-Deklarator dazu kommen und die Standard-Lib soll meines Wissens entsprechend geändert werden.
D.h. der Flaschenhals wird in Zukunft nicht durch eine neue Library eliminiert, sondern durch ein neues Sprachfeature. Ist natürlich etwas dumm gelaufen für die SPL-Entwickler.

[Dravere]

@Bulli,
Du hast ein falsches Beispiel genommen:
http://www.cplusplus.com/reference/stl/vector/push_back/

Da wird eine Reference auf ein konstantes Objekt übergeben. Die Kopie muss am Ende sowieso passieren, aber sie wird nur ein einziges Mal ausgeführt und zwar dann, wenn sie benötigt wird

Zudem muss man nie vergessen, dass ein Kompiler auch Kopien optimieren kann, manchmal sogar besser als Referenzen.

Viel wichtiger würde ich Ranges empfinden. 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.
Ich habe allerdings so meine Zweifel, dass die SPL Ranges umsetzt, konnte jedenfalls auf die schnelle nichts finden

Grüssli

[Shade Of Mine]

Dravere schrieb:

Da wird eine Reference auf ein konstantes Objekt übergeben. Die Kopie muss am Ende sowieso passieren, aber sie wird nur ein einziges Mal ausgeführt und zwar dann, wenn sie benötigt wird

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

[Bulli]

Da wird eine Reference auf ein konstantes Objekt übergeben. Die Kopie muss am Ende sowieso passieren, aber sie wird nur ein einziges Mal ausgeführt und zwar dann, wenn sie benötigt wird

Ist kein falsches Beispiel, da genaud ein solches auch vom Komitee genutzt wird. Der Parameter der Member-Funktion ist zwar eine Referenz, und muß nicht kopiert werden, aber wenn das Objekt in den Container muß, wird es eine Kopie. Kann ja auch garnicht anders sein, da wir ja sowas nicht machen können.

vector<string&> vec; // ERROR

Das ist ja ein beliebter Anfängerfehler, das man Referenzen im Container speichern will, was aber dummerweise nicht geht. Deshalb wird es den &&-Deklarator geben, der Objekte "bewegt"! Also kein Copy und kein Reference, sondern ein Move. Zumindest habe ich das nebenbei mitbekommen... genaue Definition müsste man noch mal nachschlagen.

[kA]

Bulli schrieb:

ein &&-Deklarator

Was ist denn das?

[Dravere]

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.

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.

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 .

Grüssli

[Bulli]

Dravere schrieb:

• Nonstandard – the STL approach has not been adopted by the broader industry. Instead, the Java class library has become the baseline against which other frameworks are measured.

- Kein Standard, nicht aktzeptiert von der Industrie, Java ist übermächtig ... klaaaar

Das haben die sicherlich nicht so gemeint, sondern das die C++-Industrie die C++-Std-Lib nicht akzeptiert! Sehr schönes Beispiel ist Qt, MFC, wxWdigets u.a. Die bauen alle ihre eigene Std-Lib und haben keine Beziehung zu dieser... wobei es bei diesen wohl eher historisch bedingt ist (alle schon existent, bevor es eine Std-Lib gab). Aber es gibt auch genug neue Libs die die Std-Lib meiden.

Jedenfalls geht es in dem Punkt nicht um die allgemeine IT-Industrie, sondern um C++-Libs die selber die STd-Lib meiden. Leider stimmt das. Aber andererseits führt SPL genau diesen Missgedanken weiter. Was sie ja eigentlich anprangern.

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