Alternativen zu den std-IOStreams

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.

otze

RHBaum schrieb:

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

Offensichtlich gibt es einen Unterschied zwischen formatiertem output (Konsole, human readable) und serialisierung (kompakt, mit metainformationen und nicht human-readable).

WIe willst du das mit einem Interface alleine abbilden?

Ethon

Wegen der Performance. Ich habe mal auf Linux die statfiles im Procfs geparsed, sehen etwa so aus:

[ferler@notebook-fedora17 ~]$ cat /proc/self/stat
2759 (cat) R 2706 2759 2706 34816 2759 4202496 194 0 0 0 0 0 0 0 20 0 1 0 122713 109428736 125 18446744073709551615 4194304 4238049 140737429230192 140737429230192 226698873072 0 0 0 0 0 0 0 17 5 0 0 0 0 0 6335480 6337168 36696064 140737429234750 140737429234770 140737429234770 140737429237739 0

Dabei waren die C++ Streams ca doppelt so schnell wie fscanf. Von wegen scheiß Performance.
Obwohl, wer beim Parsen Performance will, sollte Boost.Spirit nehmen ...

Swordfish

...

Kellerautomat

Und wie baue ich einen iostream, der mit sockets arbeitet? Das wuerde mich mal interessieren. Und was ist eingentlich mit asynchroner IO?

Ethon

Kellerautomat schrieb:

Und wie baue ich einen iostream, der mit sockets arbeitet? Das wuerde mich mal interessieren. Und was ist eingentlich mit asynchroner IO?

Schau dir mal Boost.Iostream an. Bau dir deinen eigenen Streambuffer/sink.
Ansonsten gibt es soetwas in Boost.Asio schon, nennt sich boost::asio::ip::tcp::iostream