Filestreams mit wchar_t?
-
Ich schreibe gerade ein Programm unter Windows mit Unicode. Da ich aber noch nicht so mit der WinAPI-Fileverwaltung zurechtkomme (besser gesagt von ihr noch nichts gehört habe), will ich noch die C++-Fileverwaltung benützen - was laut Petzold auch kein Problem ist.
Doch bei Unicode habe ich überall TCHAR (definiert entweder als char oder als wchar_t - je nachdem). Da ich Unicode benütze ist TCHAR ein wchar_t. Filename ist eine solche Variable, diese will ich nun an ifstream.open() übergeben. Doch wie erwartet macht er aus einem wchar_t* (besser gesagt unsigned short*) keinen const char*
Was kann ich da tun? Die STL wird doch wchar_t nicht nur so zum Spaß eingebaut haben sondern auch hoffentlich damit umgehen können.
BTW: Ich will nicht das der Stream dann statt einem char ein wchar_t ausliest - ich will bloß, dass eine Funktion wie open wchar_t als Parameter nimmt!
MfG SideWinder
-
ich glaub die Dateinamen können nicht mit wchar_t angegeben werden. Da musst du normale chars für nehmen
-
kingruedi schrieb:
ich glaub die Dateinamen können nicht mit wchar_t angegeben werden. Da musst du normale chars für nehmen
Das heißt die C++-Dateiverwaltung ist für Unicode-Programme nicht zu gebrauchen? Na wunderbar :(.
MfG SideWinder
-
Hallo,
schreiben und lesen kannst du wchar_t. Nur zum Öffnen brauchst du char. Hast du so komplizierte Filenames, dass eine Umwandlung wchar_t* -> char* als Lösung nicht möglich ist?
-
Nur zum Öffnen brauchst du char.
gibt es auch einen vernünftigen grund warum die open methode bzw. der konstruktor nicht mit wchar arbeitet?
-
HumeSikkins schrieb:
Hallo,
schreiben und lesen kannst du wchar_t. Nur zum Öffnen brauchst du char. Hast du so komplizierte Filenames, dass eine Umwandlung wchar_t* -> char* als Lösung nicht möglich ist?Nein solch komplizierte Filenames habe ich auf meinem Rechner zum Glück nicht. Aber es gibt selbst Orte in Europa die Unicode ausnützen (dH. mehr als die 8 ersten Bit).
Ja okay, derzeit könnte ich auch noch ohne Probleme hier casten, aber die Profis machens doch auch irgendwie (nein eben oft nicht mit WinAPI-Filefunktionen - laut Petzold).
questor schrieb:
Nur zum Öffnen brauchst du char.
gibt es auch einen vernünftigen grund warum die open methode bzw. der konstruktor nicht mit wchar arbeitet?
*mich auch interessieren würde*
MfG SideWinder
-
Das mit dem mangelnden Unicode finde ich auch nervig (ging mir schon in Delphi immer so...). IMHO ist es ein Bug in einer Anwendung, wenn man nicht alle vom BS aus legalen Dateinamen mit ihr öffnen kann.
http://www.boost.org/libs/filesystem/doc/faq.htm
Da ist immerhin die Begründung aufgeführt, warum boost::filesystem keinen Support für wstrings hat, vielleicht war die auch ausschlaggebend für ifstream. IMHO trotzdem ein Loch in der Standardbibliothek (und boost::filesystem, das ich auch gerne benutzen würde).
-
naja, ich finde es eh schwierig, Dateien nicht mit normalen ASCII Codes zu benennen, da man ansonsten leicht Probleme bekommt, wenn a) das Filesystem nur 7/8-Bit für die Dateinamen zur Verfügung stellt oder b) ein anderer Zeichensatz benutzt wird. Natürlich ist es schwer einem Japaner zu sagen, nein nein japanisch geht nicht, schreib schön ASCII. Aber leider ist das mit den Zeichensätzen/Koodierungen auf dem Computer IMHO der letzte (man Verzeihe mir den Ausdruck) scheiß.
-
Der Komfort des Users sollte aber IMHO vor dem des Programmierers stehen.
-
kingruedi schrieb:
naja, ich finde es eh schwierig, Dateien nicht mit normalen ASCII Codes zu benennen, da man ansonsten leicht Probleme bekommt, wenn a) das Filesystem nur 7/8-Bit für die Dateinamen zur Verfügung stellt oder b) ein anderer Zeichensatz benutzt wird. Natürlich ist es schwer einem Japaner zu sagen, nein nein japanisch geht nicht, schreib schön ASCII. Aber leider ist das mit den Zeichensätzen/Koodierungen auf dem Computer IMHO der letzte (man Verzeihe mir den Ausdruck) scheiß.
Welche Probleme kann es da geben? Wenn das System nur 7/8-Bit für die Dateinamen zur Verfügung stellt wird es entweder in dieser Sprachversion sowieso nur 7/8-Bit benötigen oder gibt eben einen Fehlercode zurück. ZB könnte ja ein ifstream der mit Dateinamen für w_chart den Stream auf "Bad" stellen wenn es das System nicht zulässt.
Zweitens wie du schon sagst: Was wenn nur 7Bit da sind und ich übergebe char? Oha...
Drittens, wenn du den Petzold liest kannst du von Unicode nicht mehr genug bekommen ;). Es ist wirklich die Lösung. Ein großer Nachteil ist natürlich der doppelte Speicherverbrauch - der allerdings heute bei Strings kleiner als 1MB fast gar nicht mehr auffällt.
Also ich würde alles mit Unicodestrings machen wenn es denn möglich wäre. So muss ich jetzt entweder die WinAPI-Dateiverwaltung benützen oder auf Unicode verzichten.
MfG SideWinder
-
Wenn das System nur 7/8-Bit für die Dateinamen zur Verfügung stellt wird es entweder in dieser Sprachversion sowieso nur 7/8-Bit benötigen oder gibt eben einen Fehlercode zurück.
in dem Fall der C++ Streams geht das. Aber ich meinte das auf eine andere Situation bezogen, angenommen du kopierst eine Datei vom einen FS in das andere, schon kannst du ein dummes Problem haben. Deswegen nur ASCII Zeichen für Dateinamen
Es ist wirklich die Lösung. Ein großer Nachteil ist natürlich der doppelte Speicherverbrauch
Die Lösung ist UTF-8.
Nur leider weiss ich nicht genau wie man in C++ mit UTF-8 arbeiten soll. Bashar meinte, dass man UTF-8 intern gar nicht benutzen soll und intern dann doch mit wchar_t arbeitet, weil die Kodierung eben so komplex ist.
-
[oops]