Mein Problem mit den Umlauten

[hirnfrei]

Also ich kann mich auf den Kopf stellen, ich bekomme kein äöü verglichen. Habe jetzt meine Funktion auch auf STRING umgestellt, hilft aber auch nicht. Auch locale hat nichts gebracht.

Lustig ist, wenn ich

printf("%d\n", 'ä');

verwende, dann bekomme ich in der Konsole

50084

zurück. Drehe ich den Spiess aber um mittels

printf("%c\n", 50084);

bekomme ich nur ein Symbol zurück.

Hätte ja nicht gedacht, dass drei so kleine Zeichen das Leben so schwer machen können. Zumal ich zu meinen Hochzeiten im Programmieren, das war auf dem Amiga mit StormC, damit nie Probleme hatte. Da hatte ich eine eigene Mailinglist aufgebaut, die auch nach Wörtern mit Sonderzeichen suchen konnte und das hat nie Probleme gemacht.

[Mxt]

printf("%d\n", 'ä');

das gibt bei mir unter Windows -28. Das (signed) char ist größer als 127 und wird in einen int umgewandelt, klingt plausibel.

Erzähl mal mehr über Editor, OS und Compiler.

[i_make_it]

Das Problem gibt es auch im gewerblichen Bereich öfters.
Der Mainframe spricht ASCII, der Middleware Server ANSI und das Webfontend Unicode.
Grade wenn das dann von 3 Verschiedenen Anbietern kommt (von denen keiner über den eigenen Tellerrand schaut) macht die Integration besonders viel spaß.
Üblicherweise einigt man sich dann auf eine Codierung und schreibt für die anderen beiden je einen Parser, der eine Umcodierung vornimmt bevor man mit der Verarbeitung beginnt.

Wenn der Text aus Dateien eingelesen wird, efentuell mal in den Metadaten der Dateien checken ob dort das Codierungsformat angegeben ist.
Ansonsten über das Dateiformat (nicht nur die Dateierweiterung des Namens) selektieren.

[hirnfrei]

Das ist eine Eingabe mit getchar(). Wird korrekt eingelesen und mit cout auch wieder korrekt ausgegeben.

OS: Gentoo Linux 64 Bit
IDE: Qt-Creator 3.4.2
Compiter; GCC 4.9.3 64 Bit

[Mxt]

Ja, wie schon gesagt, schein mir nicht der Wert zur Laufzeit das Problem zu sein, sondern die Konstante 'ä' im Quelltext. Das scheint ja die "multi character constant" zu sein.

Da es ja C++ ist, was liefert denn

int main()
{
    auto c = 'ä';
    std::cout << sizeof(c) << " " << typeid(c).name() << std::endl;

    return 0;
}

bei dir ?

Wirklich "1 char" ?

[hirnfrei]

Da bekomme ich

Fehler: 'c' does not name a type
   auto c = 'ä';
          ^

zurück...

[Mxt]

Spannend.

Visual Studio 2015 hat ja zwei C++ Compiler. Wenn ich

auto c = 'ä';

mit Clang übersetze, produziert das 'ä' auch eine Warnung.

warning : illegal character encoding in character literal [-Winvalid-source-encoding]
auto c = '<E4>';

das ^ welches die Fehlerposition markiert, steht beim ersten '


Kombiniere, das 'ä' ist anscheinend nicht überall erlaubt und tut nicht was du meinst. Das muss ich auch mal weiter erforschen. Da ist mir was bisher entgangen.

- - - Aktualisiert - - -

=======

Ok,

die Meldung " 'c' does not name a type " kommt wohl eher daher, dass kein C++11 oder 14 eingeschaltet ist und hat somit nicht direkt mit dem Problem zu tun.

Ansonsten wollen g++ oder clang wohl lieber Unicode Quelltextdateien, wenn du da mit Umlauten in Literalen arbeiten willst. Ob einzelne oder doppelte Anführungszeichen macht wohl keinen Unterschied.

Dann nehm für deinen Vergleich halt das ä als Hexkonstante, so in der Art

const char c = 0xe4;

oder was immer der Code des Zeichens bei dir ist.

[HaWe]

wenn ich mich nicht irre, liest die C-read (scan, getc oder C++ << -) Funktion von stdin nicht einen unsigned char sondern ein int16_t. Man liest ja aus einem FILE * stream und da wird auch grundsätzlich bei eof() eine -1 zurückgegeben (erinnere mich dunkel an so etwas), also kann es kein uchar sein. Die Codierung deutscher Umlaute und Sonderzeichen jenseits ASCII 127 ist dennoch ungewiss.

[Mxt]

Ich habe jetzt auch noch in mehrere Bücher geschaut und außer "das ist implementierungsabhängig" nicht viel gefunden.

Meine Vermutung ist, bei

if(wort[i] == 'ä')

betrachtet der g++ die rechte Seite des Vergleichs als int, also wahrscheinlich einen etwas größeren Zahlenwert (228 ?). Wenn wort ein char Array ist, werden die Werte auf der linken Seite vor dem Vergleich nach int umgewandelt, da kommen dann nur Werte von -126 bis 127 raus, der Vergleich schlägt also immer fehl. (Da holt man sich auch noch wieder das Problem rein, dass auf ARM ein char vorzeichlos ist und auf Intel eines hat.)

Wenn ich meinen Raspi wieder mal auf Arch Linux umgesteckt habe, muss ich das mal mit einem aktuellen g++ 5.3.x vergleichen.

Wahrscheinlich ist man mit den Präfixvarianten für Stringkonstanten sicherer, also L"text", U"text" oder u"text", dann hat man aber immer Unicode in verschiedenen Varianten.

Sonst halt Zahlenkonstanten statt Zeichen, oder eben in Konsolenanwendungen immer englisch schreiben.