wirklich ernst gemeinte frage

Shade Of Mine schrieb:

+fricky schrieb:

Shade Of Mine schrieb:

nein.
du kannst sogar UGUBUGU-72 kodierte daten auslesen

was den codeschnipsel von tftnet ein klein wenig länger machen würde, nicht wahr? aber sag an, wie geht das?

der code bleibt gleich. die daten in der datei haben nichts mit dem file objekt ansich zu tun.

wenn der code gleich bleibt, dann muss 'ifstream' ugubugu-72 kodierte dateien selbständig erkennen und dekodieren können, oder wie soll man das verstehen? man muss wirklich nichts weiter unternehmen, sehe ich das richtig?

Shade Of Mine

+fricky schrieb:

wenn der code gleich bleibt, dann muss 'ifstream' ugubugu-72 kodierte dateien selbständig erkennen und dekodieren können, oder wie soll man das verstehen? man muss wirklich nichts weiter unternehmen, sehe ich das richtig?

Dem File Objekt ist es total egal was in der Datei steht.
uU willst du ein std::transform darauf ausführen oder die daten in einen ugubugu-string packen. dem file objekt ist es egal was es für daten enthält.

das hat den netten vorteil dass eine datei unterschiedliche daten enthalten kann.

Artchi

ssssssssssssssssasd schrieb:

Shade Of Mine schrieb:

der code bleibt gleich. die daten in der datei haben nichts mit dem file objekt ansich zu tun.

Wo ist denn überhaupt das file object im c++ code?

Weiß nicht was du mit Fileobject meinst. Aber ich denke mal, du meinst das Filestream-Object? Das ist heißt in :

std::ifstream in((std::string(dir) + "/" + file).c_str());
              ^^

Übrigens, das mit dem c_str() im Filestream-Path hat sich doch mit C++0X erledigt. Das war wirklich eine Schande, das es nicht schon C++2003 behoben wurde! Aber besser spät als nie.

Shade Of Mine schrieb:

uU willst du ein std::transform darauf ausführen oder die daten in einen ugubugu-string packen.

ach so, dann versteht std::transform das ugubugu-72 format. und wieso u.U? muss ich, oder kann ich? letzteres wäre ja dann doppelt gemoppelt, ugubugu-144 sozusagen.

Shade Of Mine schrieb:

das hat den netten vorteil dass eine datei unterschiedliche daten enthalten kann.

auch agabaga-931? ich sehe schon, ich hab c++ und seine hellseherischen fähigkeitren mal wieder massiv unterschätzt.

Artchi

Für die Konvertierung in den C++-Streams gibt es natürlich auch ein Konzept, nennt sich std::codecvt . Bsp. wenn man UTF-8-Files behandeln will:

wofstream mystr("myfile.txt");

locale loc(locale::classic(), new codecvt_utf8<wchar_t>); // codecvt_utf8
mystr.imbue(loc); // loc im Stream setzen

mystr << L"Hello" << endl;  // als UTF-8 rausschreiben

In der Std-Lib sind aber leider keine codecvts spezifiziert, es ist nur der Standard-Codeconverter vorhanden. Von Dinkumware gibt es aber eine recht umfangreiche codecvt-Sammlung.

Im kommenden C++0x werden solche Dinge wie codecvt_utf8 vorgegeben sein!

Die Locale und somit codecvt lässt sich auch an anderen Stellen, z.B. std::basic_regex , nutzen.

Artchi

+fricky schrieb:

Shade Of Mine schrieb:

uU willst du ein std::transform darauf ausführen oder die daten in einen ugubugu-string packen.

ach so, dann versteht std::transform das ugubugu-72 format. und wieso u.U? muss ich, oder kann ich? letzteres wäre ja dann doppelt gemoppelt, ugubugu-144 sozusagen.

Prinzipiell ist es irrelevant, was für eine Codierung die Daten abgelegt sind. Es sind erstmal nur dumme Byte-Werte, die man mit z.B. std::transform manipulieren kann/will.

Erst wenn du semantische Werte (z.B. Strings) hast, ist die Codierung wichtig. Es steht nirgends geschrieben, das Streams die Codierung kennen müssen. Warum auch? Ein Stream schreibt was raus oder liest was ein. Punkt! Wo ich die Codierung semantisch benötige, kann ich selber entscheiden.

Wenn ich natürlich direkt vom Filestream in einen String lese, macht es natürlich Sinn, gleich zu konvertieren. Weil der String semantisch ist, und kein dummer Byte-Haufen.
Aber wenn ich z.B. von einem Filestream in einen Vector lese, interessiert mich die UTF-Codierung nicht die Bohne!

DEvent

Artchi schrieb:

+fricky schrieb:

Shade Of Mine schrieb:

uU willst du ein std::transform darauf ausführen oder die daten in einen ugubugu-string packen.

ach so, dann versteht std::transform das ugubugu-72 format. und wieso u.U? muss ich, oder kann ich? letzteres wäre ja dann doppelt gemoppelt, ugubugu-144 sozusagen.

Prinzipiell ist es irrelevant, was für eine Codierung die Daten abgelegt sind. Es sind erstmal nur dumme Byte-Werte, die man mit z.B. std::transform manipulieren kann/will.

Wieso vergleicht ihr dann einen BufferedReader mit std::ifstream?? Die ganzen ***Reader in der Java API sind dafuer da UTF-8 Strings zu lesen und zu schreiben. D.h. sie nehmen Daten von einer beliebigen Quelle entgegen, dekodieren diese und liefern dem Benutzer ein UTF-8 String (bzw. auch in die entgegen gesetzte Richtung, erst kodieren, dann in ein beliebiges Medium speichern).

FileInput/OutputStream stream = new FileInput/OutputStream("datei"); // mehr ist da nichts in Java
BufferedInput/OutputStream buffstream = new BufferedInput/OutputStream(stream); // wenn man einen Buffer zu einem Stream braucht

[quote="DEvent"Wieso vergleicht ihr dann einen BufferedReader mit std::ifstream?? Die ganzen ***Reader in der Java API sind dafuer da UTF-8 Strings zu lesen und zu schreiben. D.h. sie nehmen Daten von einer beliebigen Quelle entgegen, dekodieren diese und liefern dem Benutzer ein UTF-8 String[/quote]echt?

DEvent schrieb:

Wieso vergleicht ihr dann einen BufferedReader mit std::ifstream?? Die ganzen ***Reader in der Java API sind dafuer da UTF-8 Strings zu lesen und zu schreiben. D.h. sie nehmen Daten von einer beliebigen Quelle entgegen, dekodieren diese und liefern dem Benutzer ein UTF-8 String

echt?

Artchi schrieb:

Prinzipiell ist es irrelevant, was für eine Codierung die Daten abgelegt sind.

prinzipiell? ne, manchmal ist es irrelevant.

Artchi schrieb:

Es sind erstmal nur dumme Byte-Werte, die man mit z.B. std::transform manipulieren kann/will.

...oder mit deinem ^^'locale/codecvt'-beispiel. aber das wollt ich ja wissen. demnach ist der code-schnipsel von tntnet nicht mit dem java-code (auch von ihm) äquivalent, da bei seinem c++ code keine umwandlung stattfindet.

echt@edit schrieb:

DEvent schrieb:

Wieso vergleicht ihr dann einen BufferedReader mit std::ifstream?? Die ganzen ***Reader in der Java API sind dafuer da UTF-8 Strings zu lesen und zu schreiben. D.h. sie nehmen Daten von einer beliebigen Quelle entgegen, dekodieren diese und liefern dem Benutzer ein UTF-8 String

echt?

warum heißen die wohl *Reader?

Benutzername_ schrieb:

echt@edit schrieb:

DEvent schrieb:

Wieso vergleicht ihr dann einen BufferedReader mit std::ifstream?? Die ganzen ***Reader in der Java API sind dafuer da UTF-8 Strings zu lesen und zu schreiben. D.h. sie nehmen Daten von einer beliebigen Quelle entgegen, dekodieren diese und liefern dem Benutzer ein UTF-8 String

echt?

warum heißen die wohl *Reader?

*UTF8Reader?