Konsequenzen von fehlender L-/_T-Kodierung von Stringliteralen...



  • Mich würde nach einer längeren Diskussion mit meinen Chef mal Interessieren was für Konsequenzen entstehen können, wenn man beim C++ Builder > 2007 & TCHAR=wchar_t die Kodierung der Strings im Quellcode weglässt. Meinem Chef sind die zusätzlichen Klammern ein Dorn im Auge (Wir migrieren derzeit von 2007 auf XE4 daher nutze ich das _T-Makro bei allen Stringliteralen). Seine Argumentation ist das der UnicodeString ja auch mit diesen Strings klar kommt.

    Aus meiner Sicht halte ich das aus mehreren Gründen problematisch. Sei es das eine Umwandlung zum einen wohl immer auch Laufzeit kostet, zum anderen sehe ich spätestens bei Umlauten durchaus ein Problem (keine Ahnung ob er die Codepage die beim Projekt eingetragen ist nutzt, oder die des konkreten Rechners).

    Was kann alles passieren und wann?



  • asc schrieb:

    Sei es das eine Umwandlung zum einen wohl immer auch Laufzeit kostet

    Ich weiß ja nicht, was ihr so für Literale im Quelltext stehen habt. Aber wenn's bei euch einigermaßen vernünftig zugeht, halte ich das für vernachlässigbar. Klar, Literalzuweisungen in "inner loops" sind dann besonders doof, aber sowas macht ohnehin keiner, der sich über Effizienz Gedanken macht.

    asc schrieb:

    zum anderen sehe ich spätestens bei Umlauten durchaus ein Problem (keine Ahnung ob er die Codepage die beim Projekt eingetragen ist nutzt, oder die des konkreten Rechners).

    Letzteres. Die Codepage des Build-Systems wird nigendwo im Binary explizit gespeichert. Deshalb beschränke ich meine Literale auf ASCII-Zeichen, und Literale sind immer in englischer Sprache. Wenn eine deutsche Fassung gewünscht ist, verwende ich dxgettext.



  • audacia schrieb:

    Die Codepage des Build-Systems wird nigendwo im Binary explizit gespeichert. Deshalb beschränke ich meine Literale auf ASCII-Zeichen, und Literale sind immer in englischer Sprache. Wenn eine deutsche Fassung gewünscht ist, verwende ich dxgettext.

    Da unser Kundenkreis ausschließlich im deutschsprachigen Raum liegt, arbeiten wir mit deutschen Texten in den Stringliteralen. Eine Internationalisierung wird für die C++ Version auch nicht mehr angestrebt.



  • Suum cuique. Literale mit Umlauten sind codepageabhängig, aber wenn eure Kunden Deutsch sprechen, werden sie wohl auch Windows-1252 verwenden. Wenn euch das reicht, dann laßt das _T() halt weg.



  • audacia schrieb:

    Suum cuique. Literale mit Umlauten sind codepageabhängig, aber wenn eure Kunden Deutsch sprechen, werden sie wohl auch Windows-1252 verwenden. Wenn euch das reicht, dann laßt das _T() halt weg.

    Deutsch sprechen sie zwar, englische Windowsversionen sind dennoch im Einsatz.


Anmelden zum Antworten