Alternativen zu den std-IOStreams

dot

Kellerautomat schrieb:

dot schrieb:

Welche Plattform?

Plattformunabhaengig natuerlich
Aber wenns nicht anderes geht, dann zumindest Windows und OS X.

Nun, plattformunabhängig wären z.B. die Standard C++ Streams. Ansonsten halt eben WinAPI und auf OSX Cocoa oder POSIX...

Nexus

Jodocus schrieb:

Wenn du zu dumm für C++ bist, dann beende dieses Leiden und hör auf, mit C++ und uns mit dem Mist auf die Nerven zu gehen.

Sei nicht gleich so intolerant. Es hat durchaus seine Berechtigung, über gewisse APIs der C++-Standardbibliothek zu diskutieren. Auch wenn "unter aller Sau" wohl nicht der richtige Ausdruck ist und nur Leute wie dich provoziert.

Jodocus schrieb:

Dass I/O-Stream so aussieht, es es aussieht, hat seine Gründe, die du einfach (noch) nicht verstanden hast.

Bei gewissen Teilen ist das Design aber einfach nur uralt.

volkard schrieb:

Hier hauts seperatedBy und ' ' leider auseinander. Auch verliert es ein wenig n Lesbarkeit.

(Haut sie auch auseinander, auch schwer lesbar, aber transform ist so komisch.)
copy(seperatedBy(fill(to_hex(ints),0,2)),' '), stdout);

Wäre eine Überlegung wert, den Range ans Ende zu nehmen. Dadurch wird das ganze zwar nicht kürzer, aber relativ lesbar.

copyTo(stdout, seperate(' ', fix_width_each(2, '0', to_hex_each(ints))));

(xxx_each(r) ist eine Kurzform für transform(xxx, r))

Ansonsten geht printf immer noch, jetzt halt typsicher

for (int i : ints)
  print_f("%02X ", i);
// oder
copy_separated(sprintf_each("%02X", ints), ' ', stdout);

Theoretisch wäre auch ein Compilezeit-Formatstring mit TMP denkbar.

Ich brainstorme nur, diesen Teil habe ich noch nicht fertig designt.

Nexus schrieb:

Baust du auf der C-Standardbibliothek auf, oder welchen Teil schreibst du neu?

Ich brauche im Prinzip nur einen Output-Container mit push_back(char) und einen Input-Container mit pop_front(), empty() und front().
Das wrappe ich momentan auf die C-Standardbibliothek. Soll so sein, dass man auch std::string oder std::vector<char> als Container verwenden kann.

knivil schrieb:

Und was hat das mit Streams zu tun? Nach deiner Beschreibung sieht das mehr wie eine Bibliothek aus, um Iteratoren zu kombinieren.

Genau, ein Stream ist ein (möglicherweise unendlicher) Range.
Eine Bibliothek muss sich nur noch auf Algorithmen und Rangewrapper konzentrieren, die sich dann beliebig komplex kombinieren lassen.

volkard

templer schrieb:

Wäre eine Überlegung wert, den Range ans Ende zu nehmen. Dadurch wird das ganze zwar nicht kürzer, aber relativ lesbar.

Wobei man bei Filter-Ketten vieilleicht auch die Pipe-Syntax lecker finden könnte.

run(extract(ints) | fix_width_each(2, '0', to_hex_each(ints)) | write(stdout));

oder statt

for (auto p : splitEach(byLine(stdin), '='))
  println(p.first, " = ", p.second);

ein

run(read(stdin) | byLine | split('=') | append(_1," ",_2) | write(stdout));

Vielleicht magst Du http://www10.informatik.uni-erlangen.de/~pflaum/pflaum/ProSeminar/exprtmpl.html ?

volkard

templer schrieb:

Wäre eine Überlegung wert, den Range ans Ende zu nehmen. Dadurch wird das ganze zwar nicht kürzer, aber relativ lesbar.
copyTo(stdout, seperate(' ', fix_width_each(2, '0', to_hex_each(ints))));
(xxx_each(r) ist eine Kurzform für transform(xxx, r))

Hmm.

run(ints,stdout,R("

arg1>>>>>>>separate(' ')>>>>transform>>>>>arg2
                               ^    ^
                               ^    ^
                              hex   ^
                                    ^
                                 width(2,'0')

"));

Da müßte man aber VIEEL Zeit haben. Aber nur das würde es lösen, daß man übersichtlich auch von drei und mehr Eingabeströmen was vermischt, verarbeitet und auf mehrere Ausgabe-Ströme/-Container verteilt.
Evtl sind die C++-Streams gar nicht das Problem, sondern die dummen linaren Programmierzeilen. ALso aufpassen, daß Du nicht aus versehen nur irrelevante Teilprobleme optimiertst, ohne was Wesentliches zu lösen. Aufßassen, daß Du nicht nur gerade die Probleme löst, die zu Deinem Lösungsansatz passen und sie dann in echten Programmen unbrauchbar sind. Das ist mir passiert, als ich auf Deinen Pfaden war, fürchte ich.

hustbaer

volkard schrieb:

Das ist mir passiert, als ich auf Deinen Pfaden war, fürchte ich.

Uns allen
(Wenn auch bei unterschiedlichen Dingen)

volkard

hustbaer schrieb:

volkard schrieb:

Das ist mir passiert, als ich auf Deinen Pfaden war, fürchte ich.

Uns allen
(Wenn auch bei unterschiedlichen Dingen)

Ich möchte betonen, daß ich viel viel konkreter dran war. Und daß ich den Pfad weiterhin für gut halte, und die manpower selber bei weitem nicht stellen kann.
In der Richtung kann ich mir einen Paradigmenwechsel vorstellen. Wobei ich eh nicht an Paradigmenwechsel glaube wie im Werbefernsehen. Sagen wir mal, 48 ätzende Konzepte ersetzen durch 4 neue noch ätzendere.

Wenn wir *ein* Iterator-Stream-Konzept haben, das greift, dann können wir wieder aufflügeln und es in Aspekten verständlich machen. Hab irgendwie das Gefühl, es ensteht eine Iteratoren-Zoo.

Skym0sh0

Kellerautomat schrieb:

Du kannst mir einfach nicht erzaehlen, dass eine API, fuer die ich ein 640-Seitiges Buch lesen muss, gut sein kann. Auf der Seitenanzahl bringe ich ein C++-Tutorial fuer Umsteiger unter.

1.- Ohne die Referenz sind das nur 342 Seiten (da aber mit allen wodrauf das Buch abzielt)
2.- Nein auf 600 Seiten kriegst du kein ordentliches C++ Tutorial unter...

@Topic: Diskutiert ihr hier jetzt über die Bibliothek von templer oder um Alternativen zu IO-Streams oder wird jetzt nur rumgeflamt.

Swordfish

...

Skym0sh0

Naja, ganz simpel sind die nicht wenn man sie expandieren möchte, dafür sollte man sich schon mit der Materie befasst haben. Und im Schnitt sind sie (meines Wissens nach) oft langsamer als printf und Co KG.

Allerdings würde ich sie trotzdem eher benutzen als jede C-Funktion, wegen der gegeben Typsicherheit, der extremen Flexibilität durch verhältnismässige einfache Mittel.

Die Frage ist halt wie intensiv man sich mit ihnen beschäftigt. Weil C++ ist nicht die Sprache in der man mal grad so sein Problem löst. Hat man es jedoch gelöst, dann ist das Programm allgemeingültig (um es mal stark zu übertreiben)

volkard

Swordfish schrieb:

btw. Möchte mich vielleicht jemand darüber aufklären, was an den std::streams so schrecklich, oder auch nur unschön ist?

Also

print(a,b,c);

finde ich netter als

cout<<a<<b<<c;

Skym0sh0

und was ist mit

print(a, b, c, s, q, w, e, r, "blablablabalbalab", s, g, g, c, a, c, /*setWidth(4)*/, 6);

und?

cout << a << b << c << s << q << w << e;
cout << r << "blablablabalbalab" << s << g << g;
cout << c << a << c << width(4) << 6 << endl;

volkard

Skym0sh0 schrieb:

Naja, ganz simpel sind die nicht wenn man sie expandieren möchte, dafür sollte man sich schon mit der Materie befasst haben. Und im Schnitt sind sie (meines Wissens nach) oft langsamer als printf und Co KG.

Meistens wohl nur deshalb, weil voreingestellt jedes Zeichen einzeln herausgetan wird, was die Sache zu einem unfairen Vergleich macht, und weil die Windows-Konsole unglaublich langsam ist.

Skym0sh0 schrieb:

Die Frage ist halt wie intensiv man sich mit ihnen beschäftigt. Weil C++ ist nicht die Sprache in der man mal grad so sein Problem löst.

Seit ich kein QBasic mehr auf der Platte habe, ist C++ eigentlich meine erste Wahl, um schnell ein Problem zu lösen. Oder auch mal Perl wegen der regexps.

Skym0sh0

Ok, also Benchmarks hab ich selbst nicht gemacht, aber ich meine, die Geschichte gabs mal hier im Forum, aber die Rahmenbedingungen kenne ich nicht...

volkard

Skym0sh0 schrieb:

und was ist mit

print(a, b, c, s, q, w, e, r, "blablablabalbalab", s, g, g, c, a, c, /*setWidth(4)*/, 6);

Wo ist das Problem?

print(a, b, c, s, q, w, e, r, "blablablabalbalab", s, g, g, c, a, c, setwidth(4),6));

Oder um cout offensichtlich statusfrei zu machen, was die Formatierung angeht (dürfte mit C++11 aber auch wegfallen, fürchte ich).

print(a, b, c, s, q, w, e, r, "blablablabalbalab", s, g, g, c, a, c, setwidth(4,6));

Skym0sh0 schrieb:

und?

cout << a << b << c << s << q << w << e;
cout << r << "blablablabalbalab" << s << g << g;
cout << c << a << c << width(4) << 6 << endl;

print(a,b,c,s,q,w,e);
print(r,"blablablabalbalab",s,g,g);
print(c,a,c,width(4),6,endl);

oder

print(a,b,c,s,q,w,e);
print(r,"blablablabalbalab",s,g,g);
println(c,a,c,width(4),6);

Swordfish

...

Nathan

Ich mag auch die <</>>-Operatoren.
ich nutze die überall, wo es sich anbietet:

main_display << sprite1 << sprite2 << depth_test(false) << rectangle << flush;

Ich finde das wesentlich besser als:

sprite1.draw(main_display);
//...
main_display.depth_test(false);
rectangle.draw(main_display;
main_display.show();

Oder meinetwegen auch:

main_display.draw(sprite1, sprite2, depth_test(false), rectangle);
main_display.show();

Oder irgendetwaqs in der Richtung.
Deswegen fände ich basic-o/istreams schön, die nicht auf Text beschränkt sind.
width(), sync_with_studio() etc. kann ich nämlich gar nicht dafür brauchen.
Und deswegen arbeite ich mit Templates, da man meine Bilder auch in Files "ausgeben" kann, was einer Speicherung gleich kommt.
Und mit >> ziehe ich mir Sub-Bitmaps aus größeren Bildern.

Edit: Das mit den Templates:

template <typename ostream>
ostream& operator << (ostream &os, const image &img)
{
    //...
}

Die "schönere" Alternative wäre:

std::basic_ostream& operator << (std::basic_ostream &os, const image &img);

RHBaum

Naja, wenn man Streams als den Zugang zur Konsole sieht, klar dann sind die IOStreams ne Überlegung, zumal man dafuer keine andere lib braucht.

Aber sollten heutzutage Streams nicht auch fuer andere dinge verwendet werden ? Also fuer alles wo Datenstroeme rein und raus sollen ....

Fallen mir auf Anhieb neben stdin/out und Dateien dutzende Dinge ein ... Serialisierung, Sockets / Pipes, Komprimierungs-Implementationen Audio / video devices.

Stellt sich mir die Frage, warum bietet kaum eine Bibliothek IOStream-Support an ? Sondern jede Bib baut eigene Stream-Interfaces ?
Warum nimmt sogar die Boost eigene ?
Am ende muss man immer, wenn mann sich nicht auf eine lib beschraenkt, standig streams adaptieren, und teilweisse ne menge unterschiedlicher teilkonzepte beachten.

Für binaerstreams zumindest waer nen einheitliches IF schon nice, vor allem eines was man auch ueber dll grenzen exportieren koennen sollte (kein template !)

Ciao ...

Nathan

Genau das in der Art habe ich doch auch schon geschrieben?

volkard schrieb:

Allgemeines C++-Geflame bitte traditionell im C-Forum oder passend im RundUmDieProgramierung.