wchar_t -> ucs / std::codevect / Konvertierung

[unskilled]

Gibt es irgendeinen (wenns sein muss auch plattformabhängigen) Weg, aus einem wchar_t (bzw. auch aus einem einfachen char ) ein ucs-encodetes Zeichen zu bekommen?
Der Standard bietet da ja z.Bsp. use_facet und codecvt an - aber imho gibt es keinen bereits implementierten Weg, an den ucs-Code des Zeichens zu kommen, da wchar_t nicht ucs-formatted ist(beim msvc zumindest nicht-da ist z.bsp. L'ä' das gleiche wie 'ä' - und da ist(zumindest in unserem ASCII-Zeichensatz) bekanntlich das erste Bit eine 1).

Noch mal zum Standard (speziell codevect::in):
Kann mir jemand eigtl sagen, ob man irgendwie den virtuellen Funktions-Aufruf wegbekommt (do_in)? Der Compiler wird den Lookup in der V-Table ja nicht wegoptimieren können, obwohl er weiß, welches Objekt er hat. Weil da schon zur Compilezeit bekannt ist (weil Template-Parameter), was ich in was konvertieren möchte.
Eigtl stören die paar Takte ja nicht, weil die Konvertierung wesentlich länger dauert - aber wenn ich einen String habe, der viele, nicht mit dem Zieltyp darstellbare, Zeichen enthält, wird die Funktion ja x-mal aufgerufen(zumindest, wenn man ein Fragezeichen oder so einfügt, ein Zeichen weiterspringt, und die Funktion dann erneut aufruft - was ja beim Chat oder Label/...-Beschriftungen sinnvoll ist)

Wenn wir einmal bei dem Thema fehlgeschlagene Konvertierung sind: Wenn ihr eine Funktion TO ConvertString<FROM, TO>(const FROM& from) hättet...
Würde euch interessieren, ob bestimmte Zeichen nicht richtig umgewandelt worden sind? Falls ja (es gibt sicherlich Dinge, wo das wichtig ist, zu wissen): wie könnte man diese Benachrichtigung denn am tollsten zur Verfügung stellen?
Mir fallen da 3 bzw. 4 Wege ein:
1)
std::pair<TO, bool /*exact*/> ConvertString<FROM, TO>(const FROM& from)
oder
2)
TO ConvertString<FROM, TO>(const FROM& from, bool& exact = true)
oder
3)
TO ConvertString<FROM, TO>(const FROM& from)
und
TO ConvertString<FROM, TO>(const FROM& from, bool& exact)

die 2) würde ich atm eigtl bevorzugen, da man bei der 1) nicht mehr einfach ConvertString<std::wstring>("asd") schreiben kann und bei der 3) hätte man doppelten Code
bei der 2) würde man allerdings in die Millionen Unterfunktionen immer eine Referenz mitübergeben müssen, obwohl der User die in >99% der Fälle eh nicht haben möchte und man selbst sie auch nur in ganz bestimmten Fällen (-> Ausnahmen) braucht:

Also noch
4)
TO ConvertString<FROM, TO>(const FROM& from)
und
TO ConvertString_Throw<FROM, TO>(const FROM& from)

Da gefällt mir aber erstens der Name nicht ganz und 2. hab ich halt auch wieder nen Haufen doppelten Code - es sei denn, ich implementiere die throw-Funktion so, dass sie 2x ConvertString aufruft (also das to quasi noch mal nach FROM umwandelt und die beiden from s vergleicht - das klingt allerdings so, als ob es der User auch gleich selbst machen könnte...)

Sry, ist ein wenig viel Text und mehrere Fragen geworden - ich hoffe, es nimmt sich trotzdem jemand die Zeit und gibt mir zumindest ein paar Stichpunkte(ich hab so gar extra Shift benutzt^^).

bb

[unskilled]

*push*

[Artchi]

Ich habe mir jetzt nicht dein ganzes Posting durch gelesen. Aber generell kann man sagen, das man in der freien Wildbahn zu dem ganzen Zeichenkonvertierungen nichts gescheites finden wird. Da ist C++ im Open Source Umfeld echt lausig.

Wenn man wirklich ernsthaft mit Zeichenkonvertierungen was machen willst bzw. muß, ist die Dinkumware Library die einzige Lösung. Die hat nämlich die Conversions Library. Da sind die wichtigsten Codepages bei. Bei denen steht, das die Binary Lizenz 800$ für 8 Entwickler kostet. Wenn du alleine bist, kannst du Glück haben und das vielleicht für 100$ bekommen. Keine Ahnung.

Jedenfalls ist mir das unerklärlich, warum es so was noch nicht als Open Source gibt.

[Nexus]

Die Multimedia-Bibliothek SFML bietet Funktionalität im Bezug auf Unicode. In der Version 2.0, die momentan in Entwicklung (und nur über SVN zugänglich) ist, wurde einiges diesbezüglich geändert. Hier hat der Entwickler kurz was dazu gesagt.

[Braunstein]

Was ist denn mit ICU?
http://site.icu-project.org/
Nützt das denn was?

[unskilled]

ICU klingt schon mal sehr gut - SFML klang mir zu umfangreich, aber ich werd mir beides bei Gelegenheit mal durchlesen - danke! : >

[Nexus]

unskilled schrieb:

SFML klang mir zu umfangreich

Du brauchst ja nicht die ganze Bibliothek zu nutzen. SFML ist in fünf Pakete unterteilt, welche einzeln kompiliert werden können. In deinem Fall bräuchtest du nur das System-Package.