strings und sonderzeichen



  • (D)Evil schrieb:

    C++ hat auch locales ... es gibt std::wstring hmm usw. ...

    Das Problem bleibt auch bei Verwendung von wstring und wcout identisch, man bekommt lediglich keine negativen Werte mehr für die ausgegebenen Zahlen, weil ein wchar_t ein unsigned short ist.
    Ein C++-string kann übrignes auch kein UTF-8, denn entweder der String ist 8Bit oder 16Bit lang. UTF-8 kannst du nur beim Speichern/Lesen mit Dateien verwenden.
    UTF-16 kann er direkt auch nicht, dass was ein wstring ist könnte man noch als ucs2 bezeichnen.

    m.



  • GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

    Macht halt ein

    char string[] = "äüö";

    ein Array von 7 char.

    Umlaute im Quellcode ist sowieso schwachsinn (außer vll in den Kommentaren ... )



  • darthdespotism schrieb:

    GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.
    Macht halt ein
    char string[] = "äüö";
    ein Array von 7 char.
    )

    Nö, bei mir nicht:

    char str[] = "äüö";
      int cnt = sizeof( str ); // liefert 4
    

    m.



  • ist ja auch korrekt:

    str = {'ä', 'ü', 'ö', 0 }
    


  • Man kann doch auch die hier einsetzen für Umlaute:

    Ä = \x8e
    ä = \x84
    Ö = \x99
    ö = \x94
    Ü = \x9a
    ü = \x81
    ß = \xe1

    MfG
    Stromberg



  • darthdespotism schrieb:

    GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

    Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.



  • Bashar schrieb:

    darthdespotism schrieb:

    GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

    Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

    Wäre eine möglichkeit probier ich nachher mal aus.



  • stringer schrieb:

    wieso steht in Temp der wert -61?

    Deine Plattform hat für den Datentyp char den Wertebereich -128 .. 127 andere 0..255. Die Norm garantiert, daß man char sowohl in "unsigend char" wie auch "signed char" konvertieren kann.

    Wenn Du nun Werte im Beriech 0..255 haben willst, mußt Du als Datentyp "unsigned char" verwenden.



  • Bashar schrieb:

    Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

    Der Compiler darf den String Byte für Byte aus der Quelldatei holen, das ist mit Sicherheit der Editor gewesen.



  • hi,
    sorry das ich jetzt erst wieder antworte, aber ich war die letzte woche nicht zuhause.
    richtig durchsteigen tue ich immer noch nicht. ich benutze ubuntu 7.10 als os, anjuta 2.2.0 als ide und g++ 4.1.3 als compiler. was muss ich machen damit ich das nun endlich hinbekomme? ich hab bei anjuta mit den verschiedenen kodierungen rumgespielt, aber nix hat bis jetzt funktioniert.

    für noch ein bisschen hilfe wäre ich sehr dankbar



  • stringer schrieb:

    was muss ich machen damit ich das nun endlich hinbekomme?

    Das macht es noch nicht ganz wie es soll, aber das verdeutlicht, daß Problem mit "unsigned" vs. "signed" char.

    #include <ostream>
    #include <iostream>
    #include <string>
    
    int main () {
            std::string Test = "ä";
            int Temp = static_cast<unsigned char>(Test[0]);
    
            std::cout << Test << std::endl;                // gibt das ä ordentlich aus
            std::cout << Test[0] << ", " << Temp << "\n";    // gibt ein falsches zeichen und -61 aus
    }
    


  • Bashar schrieb:

    darthdespotism schrieb:

    GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

    Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

    Ich glaube nicht, dass es verboten ist. Zumal es mit dem neuen Standard ja auch explizit erlaubt sein wird, UTF-8-Strings in normalen String-Literalen (char const*) abzulegen. Im Moment ist es wahrscheinlich nur nicht sonderlich portabel.



  • queer_boy schrieb:

    Bashar schrieb:

    Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

    Ich glaube nicht, dass es verboten ist. Zumal es mit dem neuen Standard ja auch explizit erlaubt sein wird, UTF-8-Strings in normalen String-Literalen (char const*) abzulegen. Im Moment ist es wahrscheinlich nur nicht sonderlich portabel.

    UTF8-Strings in String-Literalen abzulegen ist überhaupt kein größeres Problem und IMHO was vollkommen anderes, als ungefragt aus Latin1-Umlauten UTF8 zu machen.


Anmelden zum Antworten