Alternativen zu den std-IOStreams

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

Kellerautomat

Sowas sollte von Haus aus einfach sein und keine Hilfsbibliotheken brauchen.

Ethon

Kellerautomat schrieb:

Sowas sollte von Haus aus einfach sein und keine Hilfsbibliotheken brauchen.

Soso, wie oft braucht man bitte nen eigenen Streambuffer? In welcher Sprache ist soetwas absolut trivial?
Schwieriger als in Java ist es jedenfalls nicht.

Boost ist halt ne Abkürzung mit der es nur ein paar Zeilen Code sind.
So geht's mit der reinen Standardbibliothek: http://www.mr-edd.co.uk/blog/beginners_guide_streambuf

RHBaum

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?

Ich haett kein Problem das zu trennen ....
und das nen textbasiertes interface auf nem binären aufsetzt (adapter)

WIe oft in der Praxis schreibst du code, dem es egal ist, ob das Ding untendrunter text oder binär kann .... und du irgendwie wo umschalten kannst, ob text oder binär rauskommen soll, und es dann beides auch funktioniert.
Ich kaum .... warun also nicht trennen ?

Ciao ...

Ethon

RHBaum schrieb:

und das nen textbasiertes interface auf nem binären aufsetzt (adapter)

WIe oft in der Praxis schreibst du code, dem es egal ist, ob das Ding untendrunter text oder binär kann .... und du irgendwie wo umschalten kannst, ob text oder binär rauskommen soll, und es dann beides auch funktioniert.
Ich kaum .... warun also nicht trennen ?

Ciao ...

Stimmt, gerade jetzt mit Move-Semantiken wäre ja soetwas möglich, ohne das Streambuffer-Konzept über den Haufen zu werfen:

std::text_istream input(std::binary_istream("file.txt"));

Soetwas wie das Decorator-Pattern per Vererbung würds wohl nie in die STL schaffen.

Kellerautomat

Wie ist das denn jetzt mit async IO?