fstream für Unicode?!

dEUs

So, ich nochmal zu dem Thema. Das klappt so nicht, wie das dort beschrieben ist. Wenn ich nen Unicodestring übergebe, der asiatische Zeichen beinhaltet, dann wird der ANSI-String nix und als folge davon kann ifstream die datei auch nicht öffnen...
Was mach ich jetzt? Kann nciht die ganze blöde Lib umschreiben, so dass sie andere Funktionen nutzt. Also das ist ja mal echt ne ziemliche Scheiße... Was haben sich die STL-macher dabei gedacht??

rüdiger

Du könntest deinen eigenen Filestream implementieren, der wstrings als Dateinamen akzeptiert.

dEUs

ja klar
Ne, das ist mir zu aufwendig. ich glaub, ich verwende nen ganz bösen hack:
http://lists.boost.org/MailArchives/boost/msg52452.php

dEUs

Ach ne, das ist auch doof...
Hast du grad zufälligerweise nen selbst implementierten filestream zur hand?
Schreib den bestimmt nich from scratch...

HumeSikkins

dEUs schrieb:

Hast du grad zufälligerweise nen selbst implementierten filestream zur hand?

Ich sehe nicht, wie dir hier ein filestream helfen soll. Dein Problem ist doch die Zuordnung zwischen einem Unicode-Namen und einer physischen Datei. Mal abgesehen davon, dass sowas wenn überhaupt in einen streambuffer gehört, scheint mir das auch im höchsten Maß BS-abhängig zu sein. Wenn dein BS das nicht unterstützt sehe ich nicht, wie du da weiterkommen willst. Du brauchst imo also eine passende BS-Funktion, die dir ein File-Deskriptor (oder ein FILE-Handle o.Ä.) liefert. Das lesen aus der Datei ist dann wiederum kein Problem. Neben den wstreams, findest du im Netz dafür auch unzählige Filtering-Streambuffer.

HumeSikkins

BTW: Schau auch nochmal hier.

dEUs

Hallo,

ich war jetzt ganz böse und hab aus meiner STL einfach die basic_[if/f/of]stream-Klassen rauskopiert, den internen Filebuffer auf ne eigene Klasse geändert (geänderte basic_filebuf) und diese ruft beim Öffnen jetzt eine andere Funktion auf. Eine, die intern nicht fopen aufruft, sondern FOpen, welches als fopen bei Nicht-Unicode-Build und _wfopen bei Unicode-Build definiert ist. Und natürlich alle open-Funktionen und CTors auf TCHAR geändert. Und dann tut das ganze auch. Da das eh nur unter Windows laufen muss, tut das.

Bei deinem Link weiss ich nciht worauf ich das Augenmerk legen soll. Ist ein bisschen arg viel.
Meinst du möglicherweise diese Aussage:

C++ considers that the system has a single character type. It makes no
assumptions about this type, except that it is a single type. Any time
information is passed to or from the system, this is the type that is
used. Thus, filebuf requires that the name of the file have this type,
and that all reads and writes to and from the file are done in this
type. This type is called "char". And I repeat, not only must all
filenames be char[], all transfers to and from the system take place as
transfers of char

Das wiederum besagt, wenn ich es richtig verstanden habe, dass ich auch mit der char-variante der streams Dateien öffnen kann, die Unicodezeichen enthalten. Richtig?
Nur leider tut das nciht

Ne, tut's auch nicht.

[...] and that all reads and writes to and from the file are done in this
type.

Mit Standard-Mitteln kommst du da IMHO nicht weiter, du musst auf Betriebssystem-Funktionen zurückgreifen.

HumeSikkins

Optimizer schrieb:

Ne, tut's auch nicht.

[...] and that all reads and writes to and from the file are done in this
type.

Mit Standard-Mitteln kommst du da IMHO nicht weiter, du musst auf Betriebssystem-Funktionen zurückgreifen.

Das schließt aber nicht aus, dass du dazwischen mit anderen Typen arbeiten kannst. Siehe dazu die Konvertierungsmöglichkeiten der locale-facets.
Einfacher ist hier aber ein Filtering-Streampuffer, also ein weiterer Streampuffer der zwischen dem Stream und dem eigentlichen Puffer liegt. Dort kannst du beliebige Character-Konvertierungen durchführen.
Du brauchst aber BS-funktionen, für das öffnen von Dateien. Zumindest wenn du Namen verwenden willst, die sich nicht in den narrow-Zeichensatz konvertieren lassen bzw. nicht konvertiert werden sollen.

Bei deinem Link weiss ich nciht worauf ich das Augenmerk legen soll. Ist ein bisschen arg viel

Auf zwei Dinge:

http://www.boost.org/libs/filesystem/doc/faq.htm (FAQ: Why aren't wide-character names supported?) sowie auf die Beiträge von J. Kanze.

dEUs

HumeSikkins schrieb:

http://www.boost.org/libs/filesystem/doc/faq.htm (FAQ: Why aren't wide-character names supported?) sowie auf die Beiträge von J. Kanze.

Ja, diesen Beitrag der boost-FAQ hab ich mir schon angeschaut. Jetzt weiss ich wenigstens, wieso das in der STL so ist.