Alternativen zu den std-IOStreams

knivil

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

Kellerautomat

dot schrieb:

Welche Plattform?

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

Nexus

templer schrieb:

Ich bin gerade dabei, eine auf Range-Basis zu entwickeln, mit mehreren Layern und mit variadischen Templates (deshalb C++11). Dabei wird auch gleich std::string/std::wstring/std::xyzstring ersetzt. Muss halt durchgeplant sein, verschiedene Encodings, einfache Erweiterbarkeit, deshalb zieht sich das ganze mit meiner Implementierung.

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

Jodocus

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. Niemand zwingt dich, in C++ zu programmieren, es gibt genug Alternativen, wenn du mit C++ nicht zufrieden bist. Dass I/O-Stream so aussieht, es es aussieht, hat seine Gründe, die du einfach (noch) nicht verstanden hast.

volkard

knivil schrieb:

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

Damur will er wohl html-Request parsen können ohne einmal eigenen Speicher zu allokieren, sondern er bekommt nur "strings", die auf fremdspeicher zeigen, hioer den lesepuffer von cin. das parsen war eigentlich stream-aufgabe.
entsprechend will er umgekehrt wieder zusammenstreamen können, ohne was zu kopieren.

und andersrum dann wieder auch
sql=SL("select * from tbl where user='")+user+SL("' and time='")+today+SL("'");
ohne daten anzufassen. erst sql.str() würde die sachen zusammenkopieren und nur einmal malloc/new aufrufen.

Kellerautomat

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. Niemand zwingt dich, in C++ zu programmieren, es gibt genug Alternativen, wenn du mit C++ nicht zufrieden bist. Dass I/O-Stream so aussieht, es es aussieht, hat seine Gründe, die du einfach (noch) nicht verstanden hast.

Schoen dass du von deiner Ueberlegenheit so ueberzeugt bist. Hast du auch was konstruktives beizutragen? Wenn nicht, tu mir den Gefallen und verzieh dich aus meinem Thread.

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