stringvergleich ohne strncmp



  • mein problem ist, wenn der austausch-string größer als der vergleich string ist. Weiß da jemand Rat und Hilfe??
    mein code schaut zur Zeit so aus:

    #include <iostream.h>

    void replace(char[], char[]);

    void strncpy(int, int );

    char global[100] ;

    char trip[100];

    int main()

    {

    char vergl[100], austausch[100];

    cout << "globaler string ";

    cin >> global;

    cout << "\nGeben Sie den vergleich-string ein: ";

    cin >> vergl;

    cout << "\nGeben Sie den austausch-string ein: ";

    cin >> austausch;

    replace(vergl, austausch); // Aufrufen der fkt replace mit 2 parameter

    }

    void replace (char vergl[], char austausch[])

    {

    int x,i,k,j;

    for (j=0; vergl[j] != '\0'; j++); // Groesse von vergleich-string

    int p;
    for (p=0; austausch[p] != '\0'; p++);

    for (k=0; global[k] != '\0'; k++)

    { strncpy(j,k);

    for (x=0,i=0; trip[i] != '\0'; i++)

    {if (trip[i]==vergl[i])

    x++;}

    if ( x==j)

    {/*int n=k;
    for (int v=0; austausch[v] != '\0' ;v++,n++)

    global[n]=austausch[v];
    */
    for (int y=0; y<k; y++)
    cout << global[y];
    cout << austausch;
    for (int y=k+p-1; global[y] != '\0'; y++)
    cout << global[y];
    cout << endl;}
    }

    }

    void strncpy(int j, int k)

    {

    for (int l=0; l<j; l++,k++)

    {
    trip[l]=global[k] ;
    }

    }



  • samyxy schrieb:

    es wären alles char arrays

    aber stl strings haben methoden ... darum ging es mir.

    also du kannst die länge überprüfen in dem du die char array mit einer \0 escapest ... was z.B. stl strings oder andre string klassen schon implizit machen wenn du dann auf \0 überprüfst erkennst du das ende.



  • 1ntrud0r schrieb:

    also du kannst die länge überprüfen in dem du die char array mit einer \0 escapest ... was z.B. stl strings oder andre string klassen schon implizit machen wenn du dann auf \0 überprüfst erkennst du das ende.

    Das ist meines Erachtens nicht korrekt; std::strings dürfen auch '\0's beinhalten ohne dass diese das Stringende markieren würden.



  • Das ist meines Erachtens nicht korrekt; std::strings dürfen auch '\0's beinhalten ohne dass diese das Stringende markieren würden.

    Haeee ?

    std::string kapselt gemeine char *
    Und da ist definiert : \0 = Ende Zeichenkette.

    Richtig ist: bei dem std:string muss bei dem \0 der reservierte speicherbereich ned aufhoeren. das muss er aber auch bei nem char[] array nich.

    Die einzigen Zeichenketten die ich kenne, die \0 nicht als zeichenkettenende interpretieren muessen, sind BSTRs ...
    und funken tut das ganze auch nur, weil seperat ne laengenangabe gefuehrt wird, und es fuer alle stringoperationen, fuer die \0 als zeichenkettenende relevant ist, ne aequivalente funktion gibt.

    Ciao ...



  • RHBaum: Das ist nicht korrekt, probier doch mal folgendes Programm:

    #include <string>
    #include <iostream>
    
    int main()
    {
        std::string s("Hallo Welt!");
        s[5] = '\0';
        std::cout << s;
    }
    


  • Hab programm so kopiert wie es war, nur nen return 0; zugefuegt. ... (M$ ist an der stelle kleinlich, naja warnt zumindest. aber grad die muessen sich aufregen ... )

    Also unter VC++ kommt folgendes raus :

    HalloPress any key to continue!

    😃 😃 😃
    eigentlich so wie ichs erwarte wuerde...

    was kommt bei dir raus ? Oder was soll anderes rauskommen ?
    und welche umgebung ?
    hast du ne andere io impl ? (SGI bsp.)
    Hast du irgendwoe UNICODE flag gesetzt ? oder sowas ... ?

    Unter linux und gcc kann ichs erst zu hause testen ....

    Ciao ...



  • du traust Compilern, bei denen du noch return 0; dran hängen musst?
    Also mit STLport steht dort "Hallo Welt!".



  • Ich traue nich, ich arbeite damit ! 😃 Und das mit return 0 ist glaub ich das geringere vergehen ... : 😃

    STLport auf welchen system ? mit eigener IO impl oder mit der des vorhandenen systems ?

    Zuhaus hab ich auch STLPort .... muss das da mal testen, aber ich glaub es verhaelt sich normal ...

    #include <string> 
    #include <iostream> 
    
    int main() 
    { 
        char s[100];
        strcpy(s,"Hallo Welt");
        s[5] = '\0'; 
        std::cout << s; 
    }
    

    Was bringt dein compiler hier?

    #include <string> 
    #include <iostream> 
    
    int main() 
    { 
        char s[100];
        strcpy(s,"Hallo Welt");
        s[5] = 0; 
        std::cout << s; 
    }
    

    Und das funktioniert ?

    wie erklaerst du deinem compiler das ende der zeichenkette ?
    komisch das alles ist ....

    Ciao ....



  • Dann hat der VC++ dort einen Fehler (wahrscheinlich ist der operator<< falsch implementiert). Wenn du dir s.size() vorher und nachher anguckst, wirst du identische Werte erhalten.

    gcc gibt übrigens bei mir "HalloWelt!" aus.

    Edit: Dein Dekfehler beruht auf der Annahme, dass string einen herkömmlichen C-String kapselt. Das ist nicht der Fall, string ist ein spezialisierter Container für Zeichen aller Art. Vergleiche mit dem Verhalten von C-Strings sind irreführend.



  • Als was ist dann '\0' definiert ?

    in meinem buechern ... und in der MSDN (ok, keine wirklich grosse hilfe) steht ... ende zeichenkette also Wert 0 an der Position.

    was sollt ein
    printf("Hallo\0 World!");
    liefern ?

    Edit:

    Dein Dekfehler beruht auf der Annahme, dass string einen herkömmlichen C-String kapselt

    Ich dachte Zeichenketten waeren standardisiert. Das schraenkt aber dann die verwendungsmoeglichkeiten der string container stark ein.
    oder verhaelt sich s.c_str() dann korrket ... aehm wie von mir erwartet halt ?

    Edit2:
    s.size() ist auch bei M$ im nachhinein 11 ...

    Ciao....



  • Als was ist dann '\0' definiert ?

    als Zeichen mit dem Wert 0

    was sollt ein
    printf("Hallo\0 World!");
    liefern ?

    "Hallo" natürlich. Ich glaub jeder hier weiß, dass C-Strings mit 0 abgeschlossen werden.

    oder verhaelt sich s.c_str() dann korrket ... aehm wie von mir erwartet halt ?

    s.c_str() gibt einen const char* auf einen nullterminierten String zurück. Und der wird dann wie ein C-String behandelt, klar.



  • RHBaum schrieb:

    s.size() ist auch bei M$ im nachhinein 11 ...

    Das sollte Beweis genug sein, dass der String nicht kürzer wird. Der Standard verlangt übrigens, dass operator<< für string so implementiert ist, dass s.size() Zeichen ausgegeben werden (es sei denn man hat mit Stream-Manipulatoren die maximale Ausgabebreite verkleinert). => Bug in deiner Library.



  • Bug in deiner Library.

    Ist nicht meine ... Ok, ich, oder besser die Firma, haben dafuer bezahlt, trotzdem darf ich ned mit ihr machen was ich will 😃 😃 😃 Ich darf sie nur ersetzen 🙂

    Das sollte Beweis genug sein, dass der String nicht kürzer wird.

    Da formuliert M$ sich konsequent herum ....

    size_type size() const;
    The member function returns the length of the controlled sequence.

    controlled sequence, ned string .... auch bei basic_string ....

    Ciao ...



  • Du glaubst, das wirkt sich nur bei Stream-Ausgabe aus? Na dann setz mal ne \0 mittenrein und häng mit += was an. BTW finde ich es nicht gerade professionell, sich so gegen die Realität zu sträuben.



  • RHBaum schrieb:

    NEIN!

    int main() 
    { 
        string s("hallo welt");
        s[5]=0;
        cout<<s.c_str()<<' '<<s.c_str()+6;
    }
    

    Das sollte Beweis genug sein, dass der String nicht kürzer wird.

    Da formuliert M$ sich konsequent herum ....

    size_type size() const;
    The member function returns the length of the controlled sequence.

    controlled sequence, ned string .... auch bei basic_string ....

    Bloedsinn. controlled sequence ist in meinem Beispiel
    "hallo\0welt"
    und nicht "hallo"

    Oder siehst du Irgendwo stehen, dass 0 die Laenge der controlled sequence beeinflusst.
    Und was ist die controlled sequence? Die Zeichen, die der string beinhaltet.

    Ich kapier deine Argumentation nicht.

    Natuerlich kann man nicht eine 0 in den string setzen und ihn dann als C String verwenden. Denn ein C String definiert sich durch die 0 am Ende, aber ein std::string ist kein C String.



  • Ich will mich ned straeuben ... fuer mich bedeutets nur, das std::strings dann leider in der verwendung eingeschraenkt werden.
    In den meisten umgebungen laeuft rundherum alles nur mit C-strings, also die ganzen API aufrufe, egal ob windoof oder System V.
    doof find ich nur, das ich mich die ganze zeit hab drauf verlassen, weils auch in der doku so stand ...
    Das problem sind dabei ned so sehr die + operation ... sondern das berechnen erwarteter string laengen.... und befuellen von controlls.
    ich hab immer angenommen, das s.length() == strlen(s.c_str()). Ok, wenn man keine Nullzeichen hat, ists auch kein problem. und nullzeichen bekommt man per eingabe ned rein ... ned wenn man sich ned anstrengt.

    Naja, mach soweiso ned allzuviel damit, ich brauch mehr Strings mit Laengenbyte (BSTR) und leider unterstuetzt M$ keine konvetierung von std::string (welches dann nun bweisener Massen Nullzeichen kann), und BSTR's, (welche auch Nullzeichen koennen). Ich geh den umweg ueber C-Strings, und korrekter weisse muesst ich nu ne eigene Konvertierung schreiben.

    Ciao ...



  • RHBaum schrieb:

    weils auch in der doku so stand

    In welcher Doku?



  • Nur mal so zur Original Frage..
    Ich denke, die Aufgabenstellung kommt von hier (Aufgabe Nr. 😎
    und hier wurde sie bereits sehr gut beantwortet. Falls es den OP noch interessiert.



  • Bashar schrieb:

    RHBaum schrieb:

    s.size() ist auch bei M$ im nachhinein 11 ...

    Das sollte Beweis genug sein, dass der String nicht kürzer wird. Der Standard verlangt übrigens, dass operator<< für string so implementiert ist, dass s.size() Zeichen ausgegeben werden (es sei denn man hat mit Stream-Manipulatoren die maximale Ausgabebreite verkleinert). => Bug in deiner Library.

    Das hat zwar nichts mit dem Thema zu tun, aber:
    wie kann man mit den Manipulatoren die maximale Ausgabebreite verkleinern? Ich dachte sowas wie width gibt immer die *minimale* Breite an. Ist die Länge der Ausgabe aber größer, so wird der Manipulator ignoriert. Oder täusche ich mich jetzt völlig?



  • Ich hab das einfach aus diesem Satz rausgenommen:

    21.3.7.9 schrieb:

    inserts characters as if by calling os.rdbuf()->sputn(str.data(),
    n), padding as described in stage 3 of _lib.facet.num.put.virtuals_,
    where n is the smaller of os.width() and str.size()

    Vielleicht ist da auch noch ein Fehler drin (hab ja immer nur Drafts), und das heißt in Wahrheit "bigger"?


Anmelden zum Antworten