char pointer zu string-Cast

[dot]

Abgesehen davon: Willst du wirklich bei der Abfrage jedes einzelnen String komplett eine dll laden und wieder entladen!?

[RHBaum]

was sagt denn der Standard zum Thema std::string und in deren Puffer Schreiben ???
Glaub hier gabs schon öfter kontroverse Disskussionen, ob nen String am Stueck gespeichert werden muss, und ob der [] wirklich Zeiger liefern muss, deren werte auch fuer folgende Elemente gelten ?

Also in 99,999999999999% der Fälle wirds wahrscheinlich so sein ^^
aber um auf 100% sicherheit zu kommen, wuerd ich std::vector<char> als schreibpuffer nehmen ... da die groesse vorher scho kennst, vielleicht auch std::array wenn c++11 schon nutzen darfst .... , bzw boost::array

Ist ne zusaetzliche kopie .... ja, doof. Aber vielleicht kannst statt dem std::string direkt mit der char zeiger weiterarbeiten, dann vermeidest die vielleicht doch ...

Ciao ....

[SeppJ]

RHBaum schrieb:

was sagt denn der Standard zum Thema std::string und in deren Puffer Schreiben ???

Ist verboten.

[Sone]

SeppJ schrieb:

RHBaum schrieb:

was sagt denn der Standard zum Thema std::string und in deren Puffer Schreiben ???

Ist verboten.

Wo steht das?
Natürlich sind alle Zeichen kontinuierlich und konsekutiv:

The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string objects, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0 <= n < s.size() .

Und das schreiben in den Puffer ist natürlich auch erlaubt, da ich nur auf die Zeichen im Speicher zugreife als hätte ich einen Zeiger auf sie.

Ist ne zusaetzliche kopie .... ja, doof.

Nicht wenn du movest.

[SeppJ]

Oh, haben sie das tatsächlich aktualisiert? Ich hatte noch C++03 im Kopf, da war das definitiv nicht so.

[RHBaum]

Oh, haben sie das tatsächlich aktualisiert? Ich hatte noch C++03 im Kopf, da war das definitiv nicht so.

Jo, glaub das haette früher ne ganze Menge an Disskusiionen im Keim erstickt und ein paar recht exotische STL impls verhindert ^^

Wie verhaelt sich dann eigentlich der c_str() zeiger zu, bei manipulieren der Puffer ohne Anederung der Länge? Ist das nu auch genau definiert, wenn genau der aktuelisiert werden muss ?

Nicht wenn du movest.

Ja wenn std::string als puffer nutzen kannst, kannst auch moven.
Nimmst was anderes als puffer, dann eher nicht ^^

Ciao ....

[SeppJ]

RHBaum schrieb:

Wie verhaelt sich dann eigentlich der c_str() zeiger zu, bei manipulieren der Puffer ohne Anederung der Länge? Ist das nu auch genau definiert, wenn genau der aktuelisiert werden muss ?

Der ist, ebenso wie data(), ein Zeiger auf const char und diese Constness sollte natürlich nicht weggecastet werden. Mal angenommen, der String wäre copy-on-write optimiert, dann würdest du darüber ein ganz anderes Objekt als erwartet verändern, da die Implementierung keinen Grund hatte, bei Aufruf der const-Methode eine Kopie durchzuführen.

Es wäre auch (zumindest theoretisch) vorstellbar, dass c_str() auf eine Kopie des Inhalts zeigt, anstatt auf den Originalpuffer. (In der GCC Stringimplementierung steht als Kommentar, dass dies aufgrund der Anforderungen an die Laufzeitkomplexität nicht sein könne, aber ich konnte das Argument nicht nachvollziehen. War auch vor C++11. In C++11 muss c_str O(1) sein.)

[RHBaum]

Der ist, ebenso wie data(), ein Zeiger auf const char und diese Constness sollte natürlich nicht weggecastet werden.

nee das ist schon klar .... das auf c_str() nicht draufrumschreiben darfst.

Die frage war eher, wie lange ist c_str() gültig / aktuell ... macht ein schreibvorgang auf eine interne referenz (operator [] z.b auch oder eben der Zugriff auf den puffer) den c_str() ungültig ?

Normal/Bisher musstest immer von unguenstigsten Fall ausgehen, das dir waehrend möglicher schreibenvorgaenge niemals einen c_str() halten durftest ...
bei CopyOnWrite ja soweiso nicht ^^

Für singlethread anwendungen ist das ja auch eher vorteilhaft , aber bei multithreading umgebungen kann das in extremen Fällen echt komplex werden.

c_str O(1)

Heisst doch, dass die Zeit fuer die operation constant sein muss, nicht von der Länge des Strings abgaengig oder ?
Darf sich O(1) auch was schimpfen, was einmal fast nix (eine derefernzierung) kostet und mal eine Kopie (inklussive allokation und memcopy) kostet ? Je nach internen Zustand (cache, cow puffer) der von aussen nicht ersichtlich ist ?
Dacht schon .... bedeutet das bei O(1) doch COW möglich waere.

Ciao ...

[SeppJ]

RHBaum schrieb:

Die frage war eher, wie lange ist c_str() gültig / aktuell ... macht ein schreibvorgang auf eine interne referenz (operator [] z.b auch oder eben der Zugriff auf den puffer) den c_str() ungültig ?

References, pointers, and iterators referring to the elements of a basic_string sequence may be invalidated
by the following uses of that basic_string object:
— as an argument to any standard library function taking a reference to non-const basic_string as an
argument.
— Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.

c_str O(1)

Heisst doch, dass die Zeit fuer die operation constant sein muss, nicht von der Länge des Strings abgaengig oder ?
Darf sich O(1) auch was schimpfen, was einmal fast nix (eine derefernzierung) kostet und mal eine Kopie (inklussive allokation und memcopy) kostet ? Je nach internen Zustand (cache, cow puffer) der von aussen nicht ersichtlich ist ?
Dacht schon .... bedeutet das bei O(1) doch COW möglich waere.

Da steht nichts vonwegen amortisierte Konstante, sondern bloß "constant time". Ich sehe aber auch nicht, wie dies alleine COW verhindern sollte.

Was jedoch COW in C++11 ungültig macht, ist die Kombination der beiden hier genannten Anforderungen. edit: Bei genauerem Nachdenken reicht auch die erste Forderung alleine. Es ist unmöglich, die Iteratoren bei operator[] gültig zu halten.

P.S.: Das heißt nicht, dass sich Implementierungen daran halten. Bis vor ein paar Jahren war der Default beim GCC immer noch COW. Keine Ahnung, ob das mittlerweile geändert wurde. Bei meiner Uraltversion (4.8.0 experimental) ist SSO immer noch ein experimental feature.

[camper]

SeppJ schrieb:

Was jedoch COW in C++11 ungültig macht, ist die Kombination der beiden hier genannten Anforderungen. edit: Bei genauerem Nachdenken reicht auch die erste Forderung alleine. Es ist unmöglich, die Iteratoren bei operator[] gültig zu halten.

Wieso? Wenn der Iterator intern einfach Container+Index speichert, gibt es kein Problem (da swap invalidiert).

[SeppJ]

camper schrieb:

SeppJ schrieb:

Was jedoch COW in C++11 ungültig macht, ist die Kombination der beiden hier genannten Anforderungen. edit: Bei genauerem Nachdenken reicht auch die erste Forderung alleine. Es ist unmöglich, die Iteratoren bei operator[] gültig zu halten.

Wieso? Wenn der Iterator intern einfach Container+Index speichert, gibt es kein Problem (da swap invalidiert).

Das hilft dir vielleicht beim Iterator noch (zu welchen Kosten?), aber nicht bei Zeigern und Referenzen.