string iterator nach int position

Nexus

unskilled schrieb:

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

JnZn558

Athar schrieb:

Ja, begin() abziehen.

danke sehr, finde auch diese hier ist viel elliganter.

Tachyon

Nexus schrieb:

[...]

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

volkard

Kein Quark.

Tachyon

volkard schrieb:

Kein Quark.

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

__Stefan__

ich finde std::distance cooler

unskilled

als ob du den geschwindigkeitsunterschied beim compilieren überhaupt messen(geschweigedenn merken) könntest...

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

SeppJ

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.

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

SeppJ schrieb:

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

LordJaxom

Also wenn nicht im Standard steht, dass std::string einen RandomAccessIterator anbietet, fresse ich nen Besen

Nexus

SeppJ schrieb:

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.

unskilled schrieb:

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

unskilled

manni66 schrieb:

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

Tachyon schrieb:

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?