wirklich ernst gemeinte frage

[u_ser-l]

+fricky schrieb:

goggle doch mal nach: 'java language design decisions', oder sowas. vielleicht findet sich was.

Aha: Simplicity & Familiarity & ... Nun gut ...

[tntnet]

+fricky schrieb:

zeig mal ein beispiel.

Nehmen wir doch mal das Beispiel von oben in Java:

BufferedReader in = new BufferedReader(
  new InputStreamReader(
    new FileInputStream( dir + "/" + file ) ) );

Zur Erinnerung in C++:

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

Das war in Java doch viel Einfacher - oder?

Und noch was @+fricky: Bitte nicht gleich so angreifend. Ob ich mit einem Trabbi umgehen kann oder nicht entzieht sich völlig Deiner Kenntnis. Ich bleibe auch bei meiner Meinung, dass da wo nichts ist, auch nichts bedient werden kann. Ersetze Trabbi mit Opel Corsa oder so. Der ist wirklich für jeden leichter zu bedienen, als eine Mercedes S-Klasse. Da brauche ich die Bedienungs des Navis nicht zu lernen, da es nicht vorhanden ist.

[knivil]

Der Grund, das jede C++ Library eigene Strings mitbringt, kann auch daran liegen, dass bei der Entstehung der Bibliothek schlicht und einfach std::string noch nicht verfuegbar/bekannt war.

[smokeonthewater]

tntnet schrieb:

+fricky schrieb:

zeig mal ein beispiel.

Nehmen wir doch mal das Beispiel von oben in Java:

BufferedReader in = new BufferedReader(
  new InputStreamReader(
    new FileInputStream( dir + "/" + file ) ) );

Zur Erinnerung in C++:

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

Das war in Java doch viel Einfacher - oder?

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

[+fricky]

tntnet schrieb:

+fricky schrieb:

zeig mal ein beispiel.

Nehmen wir doch mal das Beispiel von oben in Java:

BufferedReader in = new BufferedReader(
  new InputStreamReader(
    new FileInputStream( dir + "/" + file ) ) );

Zur Erinnerung in C++:

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

Das war in Java doch viel Einfacher - oder?

dass Java-programmierer einen höheren tastaturverschleiss haben, will ich nicht infrage stellen. aber zum java-code: FileInputstream liest rohdaten, InputStreamReader verwandelt den inhalt (asci, utf-8, utf-16, etc.) in den Java 'char' datentyp und 'BufferedReader' schaltet eine pufferung dazu. ingesamt eine recht einleuchtende angelegenheit, wie ich finde. 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.

tntnet schrieb:

Und noch was @+fricky: Bitte nicht gleich so angreifend. Ob ich mit einem Trabbi umgehen kann oder nicht entzieht sich völlig Deiner Kenntnis. Ich bleibe auch bei meiner Meinung, dass da wo nichts ist, auch nichts bedient werden kann. Ersetze Trabbi mit Opel Corsa oder so. Der ist wirklich für jeden leichter zu bedienen, als eine Mercedes S-Klasse. Da brauche ich die Bedienungs des Navis nicht zu lernen, da es nicht vorhanden ist.

ok, sorry, war nicht so böse gemeint, wie's sich liest. aber diese vergleiche von wegen billigkarre vs. nobelkarosse kommen immer dann, wenn einer überhaupt keine argumente hat. hier auch schon wieder. navi und high-end autoradio sind nebensächlichkeiten. beides kannste in einem schrottwagen, wie auch in 'nem maybach oder rolls-royce betreiben, ja es ist noch nicht mal ein auto nötig, damit das zeug funktioniert. also: was wolltest du damit eigentlich sagen?

[knivil]

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

[+fricky]

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.

[klischeebediener]

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

[+fricky]

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

[+fricky]

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

[ssssssssssssssssasd]

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?

[+fricky]

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.

[+fricky]

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!