Nutzt jemand std::locale für Internationalisierung?
-
Gibt es hier jemanden, der std::locale für Internationalisierung nutzt oder macht ihr das alle mit externen Frameworks?
Wenn std::locale, wie ist das so grob gelöst?
-
Hallo,
Der Bärenanteil bei der Internationalisierung ist doch wohl die Übersetzung von Texten, die der werte User zu sehen bekommt.
Und in den Weiten des Standard sehe ich da nur die Facette std::message, welche zumindest eine Schnittstelle dafür zur Verfügung stellt (aber ohne die Möglichkeit Parameter zu übergeben). Eine (echte) Implementierung dafür ist mir nicht bekannt.Ich habe vor Jahren schon mal so eine Frage im Forum gestellt, ob des Einsatzes von std::message - die Antwort war ==0. Eine Internet-Recherche brachte vor kurzen das selbe Ergebnis.
Wir benutzen Qt und auch die Tools von Qt in Projekten ohne Qt.
Gruß
Werner
-
Hallo Werner
Schade, sieht so aus, als würdest du recht behalten.
In diesem Fall werde ich mir mal ein paar andere Frameworks anschauen, danke dir für deine Antwort.
-
Ein weiteres Problem mit
std::localeist, dass es keinen gescheiten Standard gibt bezüglich der Locale-Namen und welche Locales überhaupt vorhanden sein müssen/sollten.
Unter Windows ist der Locale-Support überstd::localeauf jeden Fall recht mager.
-
Das std::Zeugs kannst du für i18n vergessen. Es ist ja nicht mal definiert welches Encoding die std::strings enthalten und entsprechend müsstest du auch ewig viel Kram bauen, damit du ein file mit std::fstreams öffnen könntest, wenn du z.B. japanische Zeichen auf verschiedenen OS unterstützen willst. Da nimmst du leichter Qt.
-
Mich wundern diese Teile der Standardbibliothek immer sehr. Normalerweise legt man ja gerade bei C++ sehr viel Wert darauf sich ewig lang über Für-und-Wider von Features Gedanken zu machen bevor man ein Feature aufnimmt. Wie lange hat man gebraucht für ganz grundlegende Dinge wie Threads nur damit die auch ja ausgereift sind.
Und dann gibt es da so Dinge die da in der Bibliothek gelandet sind und defakto unbrauchbar sind. Wie haben es die da je hineingeschafft?
MfG SideWinder
-
SideWinder schrieb:
Und dann gibt es da so Dinge die da in der Bibliothek gelandet sind und defakto unbrauchbar sind. Wie haben es die da je hineingeschafft?
'98 war das wohl alles noch etwas anders.
Ich vermute mal dass sie unbedingt die iostreams standardisieren wollten. Und dabei sind dann einige Dinge einfach durchgewinkt worden.Ausserhalb der iostreams fällt mir an unbrauchbaren Dingen jetzt auf die Schnelle nur
std::uncaught_exceptionein.
-
hustbaer schrieb:
Ausserhalb der iostreams fällt mir an unbrauchbaren Dingen jetzt auf die Schnelle nur
std::uncaught_exceptionein.Ja, natürlich.
Hast du dir schon einmal den Destruktor von sentryangeschaut?Überhaupt ist das nicht unnötig.
-
Selber

Dein Beitrag ist unklar. Schreib was du sagen willst, ich hab' keine Lust auf Ratespiele.
std::uncaught_exceptionist unbrauchbar, das steht fest. Wenn du anderer Meinung bist dann beschreib eine sinnvolle Anwendung, dann erklär ich dir gern warum es nicht funktioniert.Und BTW: was im Dtor von sentry passiert ist implementation-defined. Also... hä?
-
hustbaer schrieb:
Selber

Dein Beitrag ist unklar. Schreib was du sagen willst, ich hab' keine Lust auf Ratespiele.Er meint http://www.c-plusplus.net/forum/319608
Kurz:
std::uncaught_exceptionist unnötig und wird fälschlicherweise von den iostreams verwendet. Daraus folgt, dass der Beitrag von Sone falsch und unnötig war.
-
was im Dtor von sentry passiert ist implementation-defined.
Nein. §27.7.3.4/4.
(Vielleicht hätte ich explizit denostream::sentrysagen sollen... ja, das wäre besser gewesen
)std::uncaught_exception ist unbrauchbar, das steht fest. Wenn du anderer Meinung bist dann beschreib eine sinnvolle Anwendung, dann erklär ich dir gern warum es nicht funktioniert.
Das brauche ich gar nicht. Es gibt einfach keinen anderen Weg, festzustellen, ob Momentan eine geworfene Exception noch nicht gefangen ist.
Und jetzt erzähle mir nicht, dass man das sowieso nicht braucht und jedes Programm das diese Funktion nutzt fehlerhaft designed ist.
fälschlicherweise von den iostreams verwendet.
Die Iostreams wollen nicht den Stream flushen, wenn eine Exception geworfen ist. Ich sehe auf Anhieb nicht, warum das so ist, aber einen Grund hat's bestimmt... (oder ist das schon wieder so ein Fall von Standardkomitee macht nicht nachvollziehbare Dinge?)
-
Sone schrieb:
fälschlicherweise von den iostreams verwendet.
Die Iostreams wollen nicht den Stream flushen, wenn eine Exception geworfen ist. Ich sehe auf Anhieb nicht, warum das so ist, aber einen Grund hat's bestimmt... (oder ist das schon wieder so ein Fall von Standardkomitee macht nicht nachvollziehbare Dinge?)
Hast du auf den Link geklickt?
Der Grund ist, dass verhindert werden soll, dass 2 Exceptions gleichzeitig geworfen werden. Das ist der Fall, wenn eine Exception stack unwinding forciert und flush auch eine wirft; deshalb wird flush nicht aufgerufen. Aber uncaught_exception ist nicht geeignet, das herauszufinden.
Antworte mir erst, nachdem du diesen Link gelesen hast: http://www.gotw.ca/gotw/047.htm
-
Sone schrieb:
Und jetzt erzähle mir nicht, dass man [
std::uncaught_exception] sowieso nicht braucht und jedes Programm das diese Funktion nutzt fehlerhaft designed ist.Grr, nächstes Mal poste ich bevor ich den Link finde, und dann editiere ich später :p
-
Herb Sutter ist wie immer überzeugend.

Gut, gut, ich ziehe den Schwanz ein.
-
@Sone
Dazu braucht es keinen Herb Sutter, das hätte dir jeder erzählen können der sich etwas mit dem Themastd::uncaught_exceptionauseinandergesetzt hat. Wie z.B. ich. Oder "heiligesch.." -- bzw. der hätte nicht nur, er hat. Was du natürlich nicht gelesen bzw. einfach ignoriert hast.Herr Sone musste halt wie immer schlauer sein, auch wenn er sich mit dem Thema nicht wirklich beschäftigt hat.
-
hustbaer schrieb:
der hätte nicht nur, er hat. Was du natürlich nicht gelesen bzw. einfach ignoriert hast.
Herr Sone musste halt wie immer schlauer sein, auch wenn er sich mit dem Thema nicht wirklich beschäftigt hat.
Nein, im Artikel von Sutter wurden sehr gute Argumente und Erklärungen gebracht. Von heiligesch... habe ich nur erzählt bekommen, dass es falsch ist (und dass mein Post kacke war).
Ich dachte eben, dass sicherheitshalber eben so eine Funktion existieren sollte, ob man sie jetzt öfter braucht oder nicht spielt dabei keine Rolle. (Es gibt genug Standardbibliotheks-Teile die auch nur sehr selten gebraucht werden)
-
heiligesch.. hat diesen Thread verlinkt:
http://www.c-plusplus.net/forum/p2348495Der besteht aus heissen zwei Beiträgen, das hättest du dir schon ansehen können. Und der zweite ist von ihm, mit schön Beispielcode wo man sieht wieso
std::uncaught_exceptionsinnfrei ist.Aber statt zu gucken warum die Leute anderer Meinung sind, und schreiben dass du Mist schreibst, lieber erst nochmal behaupten dass du Recht hast. Einfach so. Weil du so toll bist.
-
Der besteht aus heissen zwei Beiträgen, das hättest du dir schon ansehen können.
Das habe ich sogar. Aber der Artikel hat von Null an die Problematik beschrieben. Das bringt einen mehr zum Nachdenken.
Edit: Oder um es anders zu sagen: Das Beispiel von heiligesch... ist - zumindest für mich - schwerer nachzuvollziehen.lieber erst nochmal behaupten dass du Recht hast. Einfach so. Weil du so toll bist.
Komm, gib's mir. Dreh mal richtig auf. Bring mich mal richtig zum Heulen.

-
Lieber Sone,
lies dir nochmal den Verlauf dieses Threads durch.
Wenn dir dann nicht auffällt was du falsch gemacht hast, dann kann bzw. will ich es dir auch nicht erklären.
Wenn schon, dann halt verdammt nochmal den Rand.
-
Zum Thems Sone
Ich lese hier schon ein paar Wochen im Forum mit, da ich mich sehr für C++ interessiere. Der Name Sone ist mir hier schon sehr oft negativ aufgefallen. Der werte User gibt seinen Senf zu irgendeinem Thema ab und wird in 99,999% der Fälle dann zu recht diskreditiert. Was ja ok ist, wenn man keine Ahnung hat aber so tut.
Aber warum in Gottes Namen tritt er dann nicht etwas kürzer, oder lernt erst einmal die Grundlagen, bevor er Unsinn verbreitet und Neulinge damit immer wieder verwirrt?