Re: STL-Streams und Unicode/UTF-16

Tech-Archive recommends: Fix windows errors by optimizing your registry

Andreas Heyer wrote:
"Ulrich Eckhardt" <eckhardt@xxxxxxxxxxxxxx> wrote:
So, ich hab' grade noch mal in den Sourcen gegraben und ich denke es
ist ein Bug dass sich der Konstruktor mit dem FILE* anders verhaelt.
Bei VC8 hast Du in jedem Konstruktor von basic_filebuf() bzw jeder
open()-Implementierung erst einen Call nach _Init() und danach einen
nach _Initcvt() welches die codecvc-Facette initialisiert, ausser bei
dem Konstruktor der einen FILE* nimmt, bei dem bleibt der Pointer auf
Null stehen und es wird halt genau das gemacht was Du richtig findest.

Es geht aber auch nicht, wenn ich das File im Textmode "r" öffne, nur
"rb" will.

Jo, ohne das "b" wird erst CR/LF konvertiert und dann wird gelesen, was dann
bei jedem Zeilenumbruch zu einem zusaetzlichen Offset von einem Byte
fuehrt. Das ist immer dann falsch wenn es nicht ASCII oder ein Derivat ist.

Bleibt die Frage, warum ios_base::binary keine Auswirkungen hat.

Ich vermute es hat eine Auswirkung, aber wenn Du das benutzt dann wird ja
auch die codecvt-Facette aus der Lokalen geladen und wieder 1wchar_t=1byte
gemacht.

Noch ein Hinweis: das 'binary' oder "b" in "wb" haben beide nichts mit der
codecvt-Facette zu tun, das laeuft auf unterschiedlichen Ebenen ab. Und ja,
es ist haesslich.

Wozu brauche ich eine Facette, wenn ich Binärdaten lese?

Naja, die Facette uebernimmt die Umwandlung zwischen Bytes(extern) und
wchar_t oder char (intern).

Wie muss ich denn manuell die codecvc einstellen, damit es trotzdem
mit UTF-16 geht?

Zuerst brauchst Du so eine Facette, die ist ja nicht Bestandteil des
Standards. Selber schreiben ist eine Moeglichkeit (aber nicht zu empfehlen
ausser es interessiert Dich), ich wuerde aber eher google oder so bemuehen.
Ich meine Boost enthielte ebenfalls einige.

Wie man die Facette in eine Lokale und die Lokale in den Stream bekommt
hatte ich in meinem ersten Posting bereits umrissen.

[1] Jedenfalls bin ich mir da zu 90% sicher, und das erklaert auch
warum auch std::wfstream() nur einen char-String im Konstruktor nimmt
und keinen wchar_t-String.

IRKS, diesen Teil haette ich loeschen wollen. Er bezog sich auf die
Vermutung dass auch wfstream mit fopen() und nicht wie man denken koennte
mit wfopen() arbeitet. Die Vermutung hatte ich gemacht bevor ich die
Sourcen gelesen hatte, danach aber vergessen die Fussnote zu loeschen.

Uli

.

Relevant Pages

  • Re: STL-Streams und Unicode/UTF-16
    ... Bug dass sich der Konstruktor mit dem FILE* anders verhaelt. ... _Initcvtwelches die codecvc-Facette initialisiert, ... Konstruktor der einen FILE* nimmt, bei dem bleibt der Pointer auf Null ... Der Filenamen hat nichts mit dem Templatetyp des Streams zu tun! ...
    (microsoft.public.de.vc)
  • Re: STL-Streams und Unicode/UTF-16
    ... genaugenommen die facet die das Locale verwendet) des Stream gesetzt. ... Benutzt man dagegen den Konstruktor mit FILE*, so unterbleibt dieser Schritt, kein facet, die eingelesenen Daten werden nicht interpretiert, sind also quasi roh. ...
    (microsoft.public.de.vc)
  • Re: STL-Streams und Unicode/UTF-16
    ... verwendet) des Stream gesetzt. ... Benutzt man dagegen den Konstruktor mit FILE*, ... Schritt, kein facet, die eingelesenen Daten werden nicht ...
    (microsoft.public.de.vc)
  • Re: STL-Streams und Unicode/UTF-16
    ... andere Locale, so dass der CRT-Default überschrieben wird? ... Bug dass sich der Konstruktor mit dem FILE* anders verhaelt. ... Konstruktor der einen FILE* nimmt, bei dem bleibt der Pointer auf Null ...
    (microsoft.public.de.vc)