std::locale::global(std::locale("german"))

[archii]

Kann mir jemand noch die Frage im Kommentar beantworten?

#include <boost/regex.hpp>
#include <locale>
#include <iostream>

int main()
{
    std::locale::global(std::locale("de_DE.UTF-8")) ;
    std::string s = "Boris Schäling";
    boost::regex expr("\\w+\\s\\w+"); // Was will er damit versuchen?
    std::cout << boost::regex_match(s, expr) << std::endl;
}

[Cox]

\\w: Ein Buchstabe, Zahl oder Unterstrich,
+: D.h., \\w muss mindestens einmal oder mehrmals vorkommen
\\s: Whitespace
...

D.h. du prüfst ob dein String aus zwei separaten Wörtern besteht.

[pumuckl]

Kleine Anmerkung:

std::string s = "Boris Schäling";

Ist kein gültiges Standard-C++, Umlaute sind nicht im Befehlszeichensatz enthalten.

[Archii]

pumuckl schrieb:

Kleine Anmerkung:

std::string s = "Boris Schäling";

Ist kein gültiges Standard-C++, Umlaute sind nicht im Befehlszeichensatz enthalten.

Ich dachte deswegen wäre das std::locale da

Cox schrieb:

\\w: Ein Buchstabe, Zahl oder Unterstrich,
+: D.h., \\w muss mindestens einmal oder mehrmals vorkommen
\\s: Whitespace
...

D.h. du prüfst ob dein String aus zwei separaten Wörtern besteht.

wtf, gibt es da eine seite für diese merkwürdigen bedeutungen?!

danke für eure antwort!

[LordJaxom]

Archii schrieb:

wtf, gibt es da eine seite für diese merkwürdigen bedeutungen?!

Jede beliebige Referenz zum Thema "reguläre Ausdrücke".

[pumuckl]

Archii schrieb:

Ich dachte deswegen wäre das std::locale da

Nein. Locales sind für die kleinen kulturellen Unterschiede, z.B. in der Darstellung von Zahlen da. Sie sind nicht dafür da, den gültigen Zeichensatz des Programmcodes bzw. den Zeichensatzumfang von char zu erweitern. (Wäre auch schlimm, sonst hätten wir sicherlich des Öfteren Spaß daran, Japanischen Sourcecode zu entziffern...)

[Archii]

pumuckl schrieb:

Archii schrieb:

Ich dachte deswegen wäre das std::locale da

Nein. Locales sind für die kleinen kulturellen Unterschiede, z.B. in der Darstellung von Zahlen da. Sie sind nicht dafür da, den gültigen Zeichensatz des Programmcodes bzw. den Zeichensatzumfang von char zu erweitern. (Wäre auch schlimm, sonst hätten wir sicherlich des Öfteren Spaß daran, Japanischen Sourcecode zu entziffern...)

Komischer Kautz wieso schreibt er es dann hin?

LordJaxom schrieb:

Archii schrieb:

wtf, gibt es da eine seite für diese merkwürdigen bedeutungen?!

Jede beliebige Referenz zum Thema "reguläre Ausdrücke".

[camper]

pumuckl schrieb:

Kleine Anmerkung:

std::string s = "Boris Schäling";

Ist kein gültiges Standard-C++, Umlaute sind nicht im Befehlszeichensatz enthalten.

Da bin ich nicht so sicher

2.13.2/5 schrieb:

... [Note: in translation phase 1, a universal-character-name is introduced whenever an actual extended character is encountered in the source text. Therefore, all extended characters are described in terms of universal-character-names. However, the actual compiler implementation may use its own native character set, so long as the same results are obtained. ]

Es erscheint mir auch sinnlos und kontraproduktiv, Umlaute in Literalen verbieten zu wollen.

[rüdiger]

Archii schrieb:

SeppJ schrieb:

Probier mal "de_DE" oder "de_DE.UTF-8".

Mit "de_DE.UTF-8" funktionierts. Mit dem "de_DE" nicht. Strange

Danke!

Ne, ist nicht "Strange". Wie genau die locales heißen ist leider systemabhängig. Unter Unixsystemen (Linux, OS X, etc.) kannst du die Namen mit locale -a rausfinden. Wenn du die aktuelle locale willst, dann nimm die aus der Umgebungsvariable $LANG (man: getenv)

pumuckl schrieb:

Kleine Anmerkung:

std::string s = "Boris Schäling";

Ist kein gültiges Standard-C++, Umlaute sind nicht im Befehlszeichensatz enthalten.

War da nicht irgend was mit extended universal characters?

[hermannkleier]

Ich habe die Zusammenhänge (noch) nicht ganz verstanden, aber vielleicht kann mir jemand die letzten Steine des Puzzles zeigen.

Vor zwei Monaten hatte ich eine Anwendung übersetzt, die seit dem klaglos ihren Dienst getan hatte. Und auf einmal erhielt ich die Meldung

locale::facet::_S_create_c_locale name not valid ,

als mein Programm ein std::locale mit dem Argument de_DE.utf8 erzeugen wollte. Natürlich hatte ich sichergestellt, dass locale -a genau dieses Argument lieferte. Neuübersetzen mit gcc 4.5.0 half nicht. Ich hatte weder die Eingabedaten noch die Konfiguration der Anwendung verändert. Aber ich hatte gcc 4.5.0 übersetzt und installiert. Die Pfade zu den neuen Bibliotheken hatte ich in der Datei /etc/ld.so.conf.d/gcc_4_5_0.conf gespeichert und den Cache des Run-time Linkers hatte ich mit ldconfig aktualisiert. Anmerkung: Unter Ubuntu Lucid Lynx wertet ldconfig alle /etc/ld.so.conf.d/*.conf Dateien aus. Der Fehler verschwand, nachdem ich die Datei /etc/ld.so.conf.d/gcc_4_5_0.conf entfernt hatte und ldconfig nochmals gestartet hatte. Natürlich hatte das keine Auswirkungen auf die Ausgabe von locale -a , da dieses mit den Bibliotheken von gcc 4.4.x gelinkt war.

gcc 4.5.0 hatte ich (wie immer) mit dem configure Skript ohne Optionen für die native Umgebung konfiguriert. Nach dem Fehlschlag habe ich gcc mit der Option

../configure --enable-clocale=gnu

neu übersetzt, die neu übersetzten Bibliotheken mit /etc/ld.so.conf.d/gcc_4_5_0.conf und ldconfig wieder ins Spiel gebracht und voilà, es geht! Die Option --enable-clocale=gnu bei der Configuration des gcc ist wesentlich, sie scheint sich auf die Erzeugung der Bibliotheken glibc auszuwirken. locale -a kann diese Probleme nicht erkennen.