3. std::string.clear()

std::string.clear()

  • S

    hi leute,

    ---------------------------------------------------------
    wozu ist die funktion gut ?

    using namespace std;

    string MyString;
    hier) MyString.clear(); ??????

    reicht es nicht wenn ich einfach wenn ich schreibe:

    MyString = ""; ?????

    PS: wann muss ich überhaupt MyString.clear() verwenden ?

    ---------------------------------------------------------

    andere frage wenn ich einen string initialisieren will wo ist da unterschied:

    a) MyString ("Hallo");
    b) MyString = "Hallo";

    ---------------------------------------------------------

    0
  • *
     

    using namespace std;

string MyString;
MyString.clear(); // evtl. effizienter als
MyString = "";

// beachte: bei MyString3 wird _nicht_ der operator=, sondern der Konstruktor aufgerufen
// einfach nur andere Schreibweise
string MyString2("Hallo");
string MyString3 = "Hallo";

MyString3 = "Hallo, Welt!"; // hier wird der operator= aufgerufen
    0
  • H

    del

    0
  • ?

    hauptmann, voll daneben

    0
  • H

    clear löscht meines Wissens nach *nur* die Fehlerflags

    Ähm. Es geht hier im std::string::clear() und das löscht keine Fehlerflags sondern den Inhalt des Strings. Die Memberfunktion verhält sich identisch zu:
    erase(begin(), end())

    andere frage wenn ich einen string initialisieren will wo ist da unterschied:

    a) MyString ("Hallo");
    b) MyString = "Hallo";

    a) heißt direct-initialization. Hier wird der Konstruktor von std::string, der ein const char*-Argument erwartet aufgerufen.
    b) heißt copy-initialization. Hier wird MyString über den *Copy*-Ctor von std::string initialisiert. Zuvor wird ein temporäres std::string-Objekt über den const char*-Ctor erstellt.
    Allerdings kann der Compiler die Erzeugung des temp-Objekts wegoptimieren und MyString direkt mit dem const char*-Ctor initialisieren. In diesem Fall ist b) also gleich a).
    Ein Unterschied besteht dennoch: Selbst wenn der Compiler den Copy-Ctor-Aufruf wegoptimiert muss bei b) der Copy-Ctor aufrufbar sein.

    Hier habe ich das ganze etwas ausführlicher beschrieben:
    http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=copyvsdirect#Answ

    0
  • H

    HumeSikkins schrieb:

    clear löscht meines Wissens nach *nur* die Fehlerflags

    Ähm. Es geht hier im std::string::clear() und das löscht keine Fehlerflags sondern den Inhalt des Strings. Die Memberfunktion verhält sich identisch zu:
    erase(begin(), end())

    oh
    entschuldige
    ich hab das nur so überflogen und dachte hier gehts um cin
    entschuldigt bitte

    0
  • E

    void string::clear() löscht den Inhalt des Strings, d.h. es entspricht erase(begin(), end()). Genau genommen also überflüssig. Warum gibt es diese Funktion eigentlich? Genau so gut könnte es ein string::sort(), vector::sort() usw. geben.

    0
  • H

    Genau genommen also überflüssig. Warum gibt es diese Funktion eigentlich?

    Ich schätze mal, damit std::string eine Container-ähnliche Schnittstelle bietet (alle STL-Container haben eine Memberfunktion clear) und damit besser in generischen Funktionen eingesetzt werden kann.

    Aber std::string ist, was das Interface angeht, sowieso eine, sagen wir mal unglückliche Klasse.

    0
  • E

    std::string::clear() wird z.B. im Buch von Andre Willms, C++ STL, 1. Auflage, 2000, Galileo, völlig verschwiegen. Dort findet man nur erase(). Die ganze Klasse std::string hätte man doch einfach durch die Container vector<char> und vector<wchar_t> ersetzen können, oder wie seht ihr das? 😃

    0
  • H

    std::string::clear() wird z.B. im Buch von Andre Willms, C++ STL, 1. Auflage, 2000, Galileo, völlig verschwiegen

    Naja, so weit verbreitet scheint die Kentniss über diese Memberfunktion nicht zu sein. Die std::strings der Dinkumware-Lib, die mit dem VC kommt, z.B. besitzt diese Memberfunktion gar nicht. Ebensowenig wie std::string::push_back.

    0
  • E

    @Hume: Kannst Du noch etwas zu meinem letzten (provokant-ironischen) Satz sagen. 😃

    0
  • H

    Kannst Du noch etwas zu meinem letzten (provokant-ironischen) Satz sagen.

    Nichts wirklich fundiertes. Technisch gesehen, kann man natürlich vector<char> und vector<wchar_t> verwenden. Zusammen mit den std::Algorithmen kann man damit std::string ohne größeren Aufwand ersetzen.
    Aus Anwendersicht halte ich das aber für problematisch. Wenn ich mit Strings arbeiten will, dann will ich mit Strings arbeiten und der entsprechende Typ sollte irgendwie auch den Namen String enthalten. Ich will also eine feine *Abstraktion* für Strings also Zeichenketten.

    Die Gleichsetzung string = vector<char> (oder Array von char) macht die Abstraktion aber kaputt, glorifiziert dafür dessen Implementation. Mir ist string = vector<char> also viel zu low level. Und überhaupt ist das in meinen irgendwie eine C-Programmierer Krankheit 🙂

    0
  • E

    @HumeSikkins: Du hast Recht. Man könnte std::string anstelle "vector" z.B. auch als "list" oder "slist" realisieren. Eigentlich müsste man einfach einen je nach Aufgabe sich selbst optimierenden (vector oder list oder ...) Container "sequence" schaffen.

    0
  • H

    Woher weiß dein Container, welche art der implementierung die beste ist?

    und wenn du etwas hast, das sich momentan wie ein Vektor verhält, weil du per Index drauf zugegriffen hast und willst nun ein Element einfügen, dann soll sich das ding in eine Liste verwandeln? Ich denke das ist langsam.

    0
  • E

    "Woher weiß dein Container, welche art der implementierung die beste ist?"

    Das kann er z.Z. in der Tat noch nicht wissen. Ist bei STL aber genau kein Problem, da man zunächst einfach

    typedef vector<itemType> container

    schreiben kann. Im Programm verwendet man nur container. Oben tauscht man später gegen

    typedef list<itemType> container

    aus und führt zur Geschwindigkeitsoptimierung Zeitmessungen durch.

    #include<...> muss auch noch an den eingesetzten Container-Typ angepasst werden.

    0
Anmelden zum Antworten