wirklich ernst gemeinte frage

+fricky schrieb:

knivil schrieb:

Ein Trabbifahrer kann jedes Auto fahren, ein Audifahrer kann aber keinen Trabbi fahren.

nicht nur das. hat sein auto 'nen kolbenklemmer, nimmt der trabbifahrer hammer, feile und macht die kiste wieder flott. so`n audifahrer verzweifelt doch schon, wenn er ein glühlämpchen wechseln muss.

Und was, wenn der Trabbifahrer ne Frau ist und der Audifahrer ein Automechaniker.

klischeebediener schrieb:

Und was, wenn der Trabbifahrer ne Frau ist und der Audifahrer ein Automechaniker.

naja, das würde vielleicht so ablaufen: die frau sagt: 'schatzi, ich glaub mit unserem auto stimmt was nicht'. der audibesitzer und automechaniker schliesst ein diagnosegerät an, studiert einen haufen diagramme, findet keinen fehler, aber lässt seinen azubi 'nen ölwechsel machen.

Shade Of Mine

+fricky schrieb:

ich weiss nicht, ob dein 'std::ifstream' das alles in einem rutsch macht, aber spätestens wenn die datei utf-8 kodiert ist, dürfte dein C++ code kläglich versagen.

nein.
du kannst sogar UGUBUGU-72 kodierte daten auslesen

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?

tntnet

smokeonthewater schrieb:

Nicht so viel Unterschied. In Java hast du ein bisschen mehr bei den Streams zu tun, in C++ hast du dafür mehr bei den std::string und wieder zurück zu c_str zu tun. Außerdem nimmt man in Java File.separator und nicht hardcodete Separatoren

Genau darauf wollte ich hinaus. Das ifstream-Beispiel wurde genannt um zu zeigen, wie umständlich C++ und wie einfach Java ist. Ich wollte mit meinem Beitrag ausdrücken (das "in Java viel Einfacher" war ironisch gemeint), dass es in beiden (allen) Sprachen Dinge gibt, die umständlich sind. Ich kann nicht einfach ein Beispiel nennen und damit beweisen, dass C++ viel schlechter ist als Java.

Ich persönlich finde das übliche Problem, einfach mal schnell eine Datei lesen in C++ einfacher zu lösen, als in Java. Das mag auch daran liegen, dass ich wesentlich mehr C++ als Java programmiert habe.

Shade Of Mine

+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.

schau dir ruhig mal c++ an, die iostreams sind das häßlichste an der stl aber dennoch deutlich besser als die java xxxreader

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?

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?