Alternativen zu den std-IOStreams

volkard schrieb:

templer schrieb:
irgendeine solche Lib da ist, denn eigentlich ist es ja ziemlich naheliegend.
for (auto p : splitEach(byLine(stdin), '='))
  println(p.first, " = ", p.second);
sagen wir mal, ich habe einen hash in einem vector<unsigned char> und will ihn als hex-string ausgeben.
wie stellste dir deine syntax vor?

Spielst du auf den Thread an, den ich nur kurz überflogen habe?

Etwa so:

copy(seperatedBy(transform(ints, fill(to_hex, '0', 2)), ' '), stdout);

knivil

Kellerautomat schrieb:

Liest von stdin zeilenweise Wertepaare getrennt durch = ein und gibt sie wieder aus.

Und bei 3 Gleichheitszeichen?

volkard

knivil schrieb:

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

Und das soll genau was machen?

byLine liest eine range und gibt eine range of ranges aus. liest hier einen stream und zeilenb aus. optimalerweise ohne was zu kopieren.
splitEach ist ein Filter, der tut jedes reinkommende Ding splitten.
Also hübsch lesbar ist das für mich, keine Frage.

volkard schrieb:

optimalerweise ohne was zu kopieren.

Genau, das ist alles lazy. Wenn man einen strikten string will, muss man das explizit sagen.

volkard

knivil schrieb:

Fuer dich sind wahrscheinlich nur die ersten 100 relevant.

Mhh, und dann kommt's drauf an, ob man für 100 Seiten eher 3 Tage braucht oder eher 3 Jahre.

Kellerautomat

knivil schrieb:

Kellerautomat schrieb:

Liest von stdin zeilenweise Wertepaare getrennt durch = ein und gibt sie wieder aus.

Und bei 3 Gleichheitszeichen?

Schlag mir lieber eine Alternative zu den IOStreams vor, als mich ueber fremden Beispielcode auszufragen.

dot

Welche Plattform?

volkard

templer schrieb:

Etwa so:
[cpp]copy(seperatedBy(transform(ints, fill(to_hex, '0', 2)), ' '), stdout);[/cpp]

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);

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)