std::basic_string



  • camper schrieb:

    Bedenke, das sowieso nur Typen mit einfacher Kopiersemantik als Zeichentypen zulässig sind, im Gegensatz zum allgemeinen Fall brauchen wir uns hier keine Gedanken um Exceptionsicherheit beim normalen Kopieren machen, denn das kann nicht fehlschlagen.

    Guter Hinweis, danke 🤡

    Naja - der einzige richtige Nachteil sind imho die traits-Fkt.
    vor allem find() - da weiß ich noch gar nicht, wie ich das mache...

    bb



  • gut - da bei find() nur im standard steht, dass traits_type::eq und nicht traits_type::find genutzt werden muss, wars doch np...

    aber ich hab noch ne Frage zu find_first_of bzw. find:

    21.3.6.3 basic_string::find_first_of schrieb:

    7.:

    size_type find_first_of ( charT c , size_type pos = 0) const
    {
     return find_first_of( basic_string<charT,traits,Allocator>(1,c),pos );
    }
    

    was ist der Unterschied dieser Fkt und der find-Überladung:

    size_type find(charT c , size_type pos = 0) const;
    

    ?

    Ich konnte keinen finden...

    bb



  • Willst du tatsächlich einen std::string mit seinen über hundert Memberfunktionen nachbauen? Ich würde mir das nochmals gut überlegen und wenigstens nicht die gleichen Fehler begehen, die schonmal gemacht wurden. 😉

    Siehe sonst auch http://www.gotw.ca/gotw/084.htm...

    unskilled @logged-off schrieb:

    was ist der Unterschied dieser Fkt und der find-Überladung:

    Ich habe das gefunden:

    <a href= schrieb:

    http://www.cplusplus.com/reference/string/string/find/">Notice that unlike member find_first_of, whenever more than one character is being searched for, it is not enough that only one of these characters match, but the entire sequence of characters to find must be matched.

    BTW: Hast du dein Passwort vergessen und das der E-Mail-Adresse ebenfalls? :p



  • Nexus schrieb:

    BTW: Hast du dein Passwort vergessen und das der E-Mail-Adresse ebenfalls? :p

    LOL. Ich habe im anderen Thread fast das gleiche gefragt. :p



  • Japp - langeweile 😉
    und so, wie ich einen meiner profs kenne, werden wir auch nächstes semester wieder genug Hausarbeiten bekommen, bei denen wir nicht eine einzige Zeile der Standard-Lib nutzen dürfen - also wirds vll nicht mal so sinnlos sein^^ und dümmer wird man dadurch ja nun auch nicht - und (um gleich die ausgeloggt-frage zu beantworten) sitz ich nur am laptop, weil mein (pc-)mainboard kaputt ist und kann hier nich ma ordentlich spielen>.< also hab ich eh nix besseres zu tun.

    zum 1. link - japp, kannte ich schon - aber wenns so nunmal so standardisiert wurde...

    zum 2. link (was du gefunden hattest):
    wenn mich nicht alles täuscht, steht dort auch kein unterschied sondern nur, dass es unterschiedliche ergebnisse liefert, sobald nicht nur ein zeichen übergeben wird!?

    bb


  • Mod

    — at(xpos+I) == str.at(I) for all elements I of the string controlled by str

    ...

    — at(xpos) == str.at(I) for some element I of the string controlled by str.

    Wenn I nur 0 sein kann, weil der entsprechende String nur ein Zeichen hat, kann es offenbar keinen Unterschied geben. Diese Überladungen existieren offensichtlich nur der Vollständigkeit halber beide als degenerierte Versionen des allgemeinen Falls.



  • camper schrieb:

    — at(xpos+I) == str.at(I) for all elements I of the string controlled by str

    ...

    — at(xpos) == str.at(I) for some element I of the string controlled by str.

    Wenn I nur 0 sein kann, weil der entsprechende String nur ein Zeichen hat, kann es offenbar keinen Unterschied geben. Diese Überladungen existieren offensichtlich nur der Vollständigkeit halber beide als degenerierte Versionen des allgemeinen Falls.

    danke



  • Und nochmal... : D

    im Gegensatz zu den 100den von find-Fkt, die lediglich traits_type::eq() ist die string-compare-fkt so definiert:

    standard schrieb:

    int compare(const basic_string &str) const
    {
    const size_type rlen = std::min(size(), str.size()); //1 Effects: Determines the effective length rlen of the strings to compare as the smallest of size() and str.size().
    return traits_type::compare(data(), str.data(), rlen); //The function then compares the two strings by calling traits::compare(data(), str.data(), rlen).
    }

    standard schrieb:

    [traits::compare]
    yields: 0 if for each i in [0,n), X::eq(p[i],q[i]) is true; else, a negative value if, for some j in [0,n), X::lt(p[j],q[j]) is true and for each i in [0,j)
    X::eq(p[i],q[i]) is true; else a positive value.

    traits::compare ist also über eq bzw lt definiert.
    ist es nun noch standard-konform, wenn man die string-compare-fkt nicht mittels der traits-compare-fkt sondern direkt mit eq implementiert?

    bb


  • Mod

    unskilled schrieb:

    traits::compare ist also über eq bzw lt definiert.

    Das betrifft aber nur die Ermittelung des Rückgabewertes. Eine nutzerdefinierte traits-Klasse könnte durchaus in diesen Funktionen noch anders beobachtbares Verhalten zusätzlich einbauen. Mit anderen Worten: im Standardfall char_traits<char>, char_traits<wchar_t> kannst du machen, was du willst, ansonsten ist es problematisch.



  • camper schrieb:

    unskilled schrieb:

    traits::compare ist also über eq bzw lt definiert.

    Das betrifft aber nur die Ermittelung des Rückgabewertes. Eine nutzerdefinierte traits-Klasse könnte durchaus in diesen Funktionen noch anders beobachtbares Verhalten zusätzlich einbauen. Mit anderen Worten: im Standardfall char_traits<char>, char_traits<wchar_t> kannst du machen, was du willst, ansonsten ist es problematisch.

    Das ich das in diesen beiden Fällen machen kann, hab ich auch schon geschlussfolgert.
    Schade - ich hatte gehofft, dass du irgend ne Stelle so deutest, dass man einen dem standard entsprechenden traits-typ angeben muss^^

    Fällt jemandem ein Fall ein, wo es sinnvoll ist, dass jmd. ein compare schreibt, welches nicht dem standard-compare entspricht? Mir ist vorhin keiner eingefallen und jetzt auch noch nicht 😉

    bb


Log in to reply