Der Link zu stackoverflow hat geholfen, danke. Die Lösung hatte
mittlerweile ich auch schon selbst, ist halt etwas indirekt die Lösung,
dachte es gibt was direkteres, aber es ist eigentlich ok so.
Deshalb mag ich die Standardbibliothek an einigen Stellen nicht so
gerne. Die Dinge sind gerne mal umständlicher als man sich wünschen
würde. Klar kann man sich die wichtigsten Funktionen auch meistens
relativ einfach selbst definieren, wie man auf der verlinkten Seite
sieht. Aber ist es nicht gerade die Aufgabe einer Standardbibliothek,
sowas schon gleich mitzubringen, statt dass sich da jeder selbst was
basteln muss?
Rolf M. schrieb:> Aber ist es nicht gerade die Aufgabe einer Standardbibliothek,> sowas schon gleich mitzubringen, statt dass sich da jeder selbst was> basteln muss?
Sehe ich auch so. Das suchen und ersetzen eines Substrings innerhalb
eines Strings ist etwas so gängiges, dass ich mich gewundert habe, dass
es da nichts fertiges gibt.
Rolf M. schrieb:> Deshalb mag ich die Standardbibliothek an einigen Stellen nicht so> gerne. Die Dinge sind gerne mal umständlicher als man sich wünschen> würde. Klar kann man sich die wichtigsten Funktionen auch meistens> relativ einfach selbst definieren, wie man auf der verlinkten Seite> sieht. Aber ist es nicht gerade die Aufgabe einer Standardbibliothek,> sowas schon gleich mitzubringen, statt dass sich da jeder selbst was> basteln muss?
Einer der Grundsätze der std-lib ist es, eine (möglichst) orthogonale
Schnittstelle anzubieten. Dieser Fall eines search-and-replace ist
ähnlich wie remove-and-erase.
Das macht aber die Benutzung unnötig umständlich, weil man eben viele
Funktionen, die häufig benötigt werden, nicht in der Form findet und
erst noch selber nachbilden muss. Deshalb arbeite ich letztendlich z.B.
lieber mit Qt als mit der Standardlib, weil ich da in der Regel eine
Funktion finde, die das tut, was ich will und ich diese nicht erst aus
mehreren Bestandteilen, die einzeln eigentlich so gut wie nie nützlich
sind, zusammenbasteln muss.
Wilhelm M. schrieb:> ähnlich wie remove-and-erase.
Das fand ich immer etwas daneben. remove ist einfach ein falscher Name,
da es nichts aus dem Container entfernt, sondern nur verschiebt. Es
verstößt damit gegen einen der wichtigsten Grundsätze des API-Designs:
Überraschungen vermeiden.
Rolf M. schrieb:> Das fand ich immer etwas daneben. remove ist einfach ein falscher Name,> da es nichts aus dem Container entfernt, sondern nur verschiebt. Es> verstößt damit gegen einen der wichtigsten Grundsätze des API-Designs:> Überraschungen vermeiden.
Würde ich so nicht sagen: ein remove bedeutet nicht, dass die Elemente
zerstört werden, sondern nur, dass sie aus dem betrachteten halboffenen
Intervall entfernt werden. Dies wird deswegen gemacht, um keinen
Laufzeitnachteil zu haben. Insofern sehr konsequent zu den Designzielen
der std-lib.
Rolf M. schrieb:> Das ist in der Theorie ja nett, aber wann braucht man das in der Praxis> mal, ohne dass man die Daten nachher auch wirklich entfernt?
Recht häufig.
Wie gesagt, die C++-stdlib versucht, eine orthogonale Schnittstelle zur
Verfügung zu stellen. Und da nun mal das Entfernen aus einem Container
und das Zerstören der Objekte wie auch im echten Leben zwei
unterschiedliche Operationen sind, wird das auch dort gemacht. Einfach,
um dem Anwender möglichst große Flexibilität zu gewähren bzw.
irgendwelche Laufzeitkosten genau dann zu bezahlen, wann er will. Hier
also bspw. erst, wenn der gesamte Container zerstört wird oder explizit
eine erase aufgerufen wird. Man kennt das ja aus vielen Bereichen, z.B.
von IEEE-1003.1 fork()/exec() oder von den IEEE-1003.2 tools nach dem
Motto: do one thing right.
Wilhelm M. schrieb:> Wie gesagt, die C++-stdlib versucht, eine orthogonale Schnittstelle zur> Verfügung zu stellen. Und da nun mal das Entfernen aus einem Container> und das Zerstören der Objekte wie auch im echten Leben zwei> unterschiedliche Operationen sind, wird das auch dort gemacht.
Naja, aber im echten Leben heißt "entfernen von Gegenständen aus einer
Kiste" nicht, dass ich die alle in der Kiste lasse und dort nur in eine
Ecke lege, sondern dass sie danach wirklich nicht mehr in der Kiste
sind.
> Einfach, um dem Anwender möglichst große Flexibilität zu gewähren bzw.> irgendwelche Laufzeitkosten genau dann zu bezahlen, wann er will.
Wobei die Laufzeitkosten durchaus höher sein können als beim direkten
Löschen, denn die Elemente müssen je nach Container ggf. umkopiert
werden, um ans Ende zu gelangen.
Rolf M. schrieb:> Wilhelm M. schrieb:>> Wie gesagt, die C++-stdlib versucht, eine orthogonale Schnittstelle zur>> Verfügung zu stellen. Und da nun mal das Entfernen aus einem Container>> und das Zerstören der Objekte wie auch im echten Leben zwei>> unterschiedliche Operationen sind, wird das auch dort gemacht.>> Naja, aber im echten Leben heißt "entfernen von Gegenständen aus einer> Kiste" nicht, dass ich die alle in der Kiste lasse und dort nur in eine> Ecke lege, sondern dass sie danach wirklich nicht mehr in der Kiste> sind.
Du vergisst dabei, dass es auch Container gibt, die in ihrer
Elementanzahl unveränderlich sind, also bspw. std::array oder statische
C-Arrays. Hier kannst Du nur logisch löschen (std::remove), denn man
kann nicht allgemein davon ausgehen, dass jeder DT einen ungültigen Wert
besitzt (int hat ihn nicht, Zeigertypen haben ihn als nullptr, und wie
ist das mit Datentyp Xyz?).
>>> Einfach, um dem Anwender möglichst große Flexibilität zu gewähren bzw.>> irgendwelche Laufzeitkosten genau dann zu bezahlen, wann er will.>> Wobei die Laufzeitkosten durchaus höher sein können als beim direkten> Löschen, denn die Elemente müssen je nach Container ggf. umkopiert> werden, um ans Ende zu gelangen.
Zudem werden die Elemente nur verschoben (wenn möglich) und nicht
kopiert (nur als fallback): das Verschieben etwa eines std::string ist
sehr billig, das Zerstören recht teuer.
Rolf M. schrieb:> Deshalb arbeite ich letztendlich z.B.> lieber mit Qt als mit der Standardlib, weil ich da in der Regel eine> Funktion finde, die das tut, was ich will und ich diese nicht erst aus> mehreren Bestandteilen, die einzeln eigentlich so gut wie nie nützlich> sind, zusammenbasteln muss.
Was aber vor allem für QString gilt. Da macht Qt einem das Leben schon
sehr angenehm.
Bei allen anderen Qt-Containern, falls man sie überhaupt nutzt, ist der
Vorteil gegenüber der Standardf-Bibliothek nicht so ausgeprägt. Als die
ursprünglich ma eingeführt wurden, mag das anders gewesen sein,
inwzischen könnte man auf die ganz verzichten.
Oliver