bb

Kann man auch besser machen:
http://www.cplusplus.com/reference/std/iterator/distance/

Das ist nicht besser. Man müsste dazu <iterator> einbinden und die Kompilierzeit erhöhen. Von der Abstraktion, dass std::distance() je nach Iteratorkategorie anders Distanzen ausrechnet, hat man bei std::string alleine gar nichts. Für dieses Beispiel spricht nichts gegen die Verwendung des operator- .

Ja, begin() abziehen.

danke sehr, finde auch diese hier ist viel elliganter.

[...]

Sorry, aber die Aussage ist Quark. Damit kann man fast alle Algos aus der Standardlib tot argumentieren.

Kein Quark.

Von Dir hätte ich so eine Aussage auch erwartet.

Imho wird auch nirgendwo im Standard geschrieben, dass std::string::iterator einen operator-(iterator) bzw operator+(iterator) anbieten muss.

distance ist jedenfalls die unabhängigere lösung - und hat (bis auf die eine zeile mehr(das include)) keine nachteile ggnüber anderer lösungen...

bb

PS:
mir fällt gerade ein, dass du die zeile nicht mal brauchen wirst - weil string wohl alleine schon iterator includieren wird(reverse_iterator ist ja immerhin dort definiert). das steht zwar so auch nicht im standard, aber man kann imho schon davon ausgehen, dass dort iterator included wird...

Imho wird auch nirgendwo im Standard geschrieben, dass std::string::iterator einen operator-(iterator) bzw operator+(iterator) anbieten muss.

Bin mir ziemlich sicher, dass doch. Bin aber zu faul zu gucken.

distance ist jedenfalls die unabhängigere lösung - und hat (bis auf die eine zeile mehr(das include)) keine nachteile ggnüber anderer lösungen...

Dies ist Abstraktion um der Abstraktion selbst willen. Wenn man nicht weiß, was für ein Container kommt, ist std::distance genau das richtige. Aber wenn man weiß, dass man einen std::string hat, kann und sollte man auch dessen Eigenschaften benutzen.

unskilled schrieb:

Imho wird auch nirgendwo im Standard geschrieben, dass std::string::iterator einen operator-(iterator) bzw operator+(iterator) anbieten muss.

Bin mir ziemlich sicher, dass doch. Bin aber zu faul zu gucken.

ich hab beim iterator-typedef nur nen verweis auf 23.1 gesehen - dort dann aber nichts von den operatoren gelesen.

im aktuellen standard weiß man nun mal nicht, welchen container string nutzt (bzw aus welchem container er besteht).
im kommenden kann man dann ohne bedenken begin abziehen.

bb

Dies ist Abstraktion um der Abstraktion selbst willen.

Genau das meinte ich.

Man kann auch std::distance() nehmen, die Vor- oder Nachteile sind nicht signifikant. Aber ich wehre mich gegen die Behauptung, std::distance() sei in diesem Falle die bessere Alternative.

Imho wird auch nirgendwo im Standard geschrieben, dass std::string::iterator einen operator-(iterator) bzw operator+(iterator) anbieten muss.

std::string::iterator ist ein Random Access Iterator. Für diese ist Arithmetik im Standard gefordert.

std::distance berechnet für Random Acess Iteratoren die Differenz dann auch einfach mit a-b. Ansonsten wird eine for-Schleife o.ä. benutzt.

Lars

std::string::iterator ist ein Random Access Iterator. Für diese ist Arithmetik im Standard gefordert.

hmm.. hab ich auf die schnelle nicht gefunden gehabt - und jz geh ich ins bett
na gut - dann ists wohl wirklich egal^^

bb

volkard schrieb:

Kein Quark.

Von Dir hätte ich so eine Aussage auch erwartet.

Was soll ich denn sonst machen? Soll ich öffentlich deswegen weinen? Schau genau zu, in wirklichkeit tue ich es schon. Was noch?