3. L"\x00DC"L"bernehmen" -> geht das auch einfacher?

L"\x00DC"L"bernehmen" -> geht das auch einfacher?

  • A

    Und führende Nullen sind keine "Mehrzeichen"? 😉

    0
  • N

    Artchi schrieb:

    Und führende Nullen sind keine "Mehrzeichen"? 😉

    Nicht, wenn sie Bestandteil einer Escape-Sequenz sind.

    0
  • Administrator

    @Nexus,
    Soweit ich weiss hat nur die Oktalschreibweise eine Begrenzung. Bei Hexadzimalzahlen wird solange dazugenommen, bis ein Zeichen kommt, welches keine Hexadezimalziffer ist.
    Bei der Oktalschreibweise ist die Beschränkung bei drei Ziffern ("\777"), also nur der Wertebereich von 0 - 511. Für ein Ü würde es zwar noch reichen, aber es hat leider auch Zeichen, die in einem höheren Bereich liegen.

    @Artchi,
    Gute Idee, aber leider nicht perfekt. Weiterer Hintergrund ist, dass ich das wxT Makro aus wxWidgets verwendet, wodurch automatisch für das Prefix L gesorgt ist, wenn es nötig ist. Also grundsätzlich schreib ich:

    wxT("\x00DC")wxT("bernehmen")

// Daher bereits eine Erleichterung:
wxT("\x00DC \bbernehmen")

    Nun folgt aber das nächste Problem, bzw. wieso diese Lösung nicht funktioniert:
    Das ist eine Beschriftung für einen Button und dieser kann mit dem Backspace-Escapezeichen nicht umgehen 😉

    Grüssli

    0
  • N

    Wenn du ohnehin schon Makros verwendest, wage ich mich vielleicht trotzdem:

    #define wxT2(TEXT1, TEXT2) wxT(TEXT1) wxT(TEXT2)

    Dann hast du zwar ein Komma und zusätzliche Anführungszeichen (wenn dich diese stören, kannst du ja auch direkt den Text übergeben und # verwenden):

    wxT2("\x00DC","bernehmen")

    Oder du machst dir ein künstliches Trennzeichen wie zum Beispiel '.' (Hauptsache Nicht-Hexadezimalziffer). Dann schreibst du den String mit dem Punkt und übergibst ihn an eine Funktion, die den Punkt entfernt und den neuen String an wxWidgets weiterreicht. Zwar etwas viel Aufwand, zudem müsstest du dich die um Speicherverwaltung kümmern, aber so könntest du immerhin ein einzelnes Stringliteral verwenden. 🙂

    0
  • Administrator

    @Nexus,
    Und wenn nun plötzlich zwei Hexadezimalziffern vorkommen? Empfiehlst du dann wxT3? 😃
    Oder womöglich sowas:

    #include <boost/preprocessor.hpp>
#include <boost/preprocessor/stringize.hpp>
#include <boost/preprocessor/seq/for_each.hpp>

#define ULTRA_DUPRA_MACRO_STRING_LITERAL(r, data, elem) wxT(BOOST_PP_STRINGIZE(elem))
#define wxTX(seq) BOOST_PP_SEQ_FOR_EACH(ULTRA_DUPRA_MACRO_STRING_LITERAL, , seq)

// Verwendung:
wxTX((test)(test)(test));

    -> Nein, Danke! 🤡

    Und das mit dem Trennzeichen und der eigenen Funktion, gut, wäre eine Lösung, aber wirklich etwas aufwendig. Da bleibe ich wohl bei meiner aktuellen Lösung und wenn es dann soweit ist, dass ich die Anwendung vollwertig mehrsprachige mache, dann wird dann der String sowieso aus einem Configfile kommen, wahrscheinlich UTF-8 kodiert und dadurch wird das Problem dann ganz verschwinden 🙂

    Grüssli

    0
  • N

    Dravere schrieb:

    Und wenn nun plötzlich zwei Hexadezimalziffern vorkommen? Empfiehlst du dann wxT3? 😃

    Klar. Für die ersten 256 Versionen hat man so ein Makro. Die restlichen kann man sich dann aus diesen zusammenbauen. 😃

    Alternativ könntest du auch bei einem Makro bleiben und

    wxT2(test,wxT2(test,test))

    verwenden, was natürlich viiiel schöner ist, als es direkt zu verwenden. :p

    Nein, ich wüsste nicht gerade eine wirklich saubere und einfache Lösung. Ob es die wohl gibt...?

    0
  • A

    Sehe gerade, das du \x benutzt. Hast du eigentlich schon mal \u anstatt \x ausprobiert? Im "Die C++ Programmiersprache" steht:

    hex-quad:
    hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit

    universal-character-name:
    \u hex-quad
    \U hex-quad hex-quad

    0
  • Administrator

    @Artchi,
    \u ist nicht für Stringliterale, sondern für den Code:

    int t\uFCre = 4; // Variable türe
std::cout << t\uFCre << std::endl;

    @Nexus,
    Es wäre wohl zu schön, wenn es da eine vernünftige Lösung gibt 🙂

    Grüssli

    0
  • A

    Dravere schrieb:

    @Artchi,
    \u ist nicht für Stringliterale, sondern für den Code:

    int t\uFCre = 4; // Variable türe
std::cout << t\uFCre << std::endl;

    Hem, das folgende kompiliert auf MSVC 8.0 und GCC 4.3.0 wunderbar:

    L"Arabic text: \u0633\u0644\u0627\u0645."

    Den String stellt die Win32 API korrekt dar.

    0
  • Administrator

    Artchi schrieb:

    Hem, das folgende kompiliert auf MSVC 8.0 und GCC 4.3.0 wunderbar:

    L"Arabic text: \u0633\u0644\u0627\u0645."

    Den String stellt die Win32 API korrekt dar.

    Ups, da ist mir ein Fehler beim Testen unterlaufen. Hab vergessen, dass es ja entweder 4 oder 8 Stellen sein müssen, zwei sind verboten, daher ging die Ausgabe nicht. Also auch mein Codebeispiel sollte lauten:

    int t\u00FCre = 4; // Variable türe
std::cout << t\u00FCre << std::endl;

    Nun gut, wahrscheinlich ist das einfach nochmals eine Ebene früher, wo das ersetzt wird. Das ist dann kein Stringescapezeichen mehr. Es funktioniert zwar, aber ob es wirklich per Standard korrekt ist, bin ich mir nicht so sicher. Naja, was solls, hauptsache es geht, es soll ja nur laufen, danach kann ich dann das SP1 erstellen 😃

    (Microsoft ist ein schlechtes Vorbild ;))

    Grüssli

    0
Anmelden zum Antworten