Ich habe 3 Funktionen:

template <typename ostream>
ostream& operator << (ostream &os, std::exception &ex);

message_box & operator << (message_box & messagebox, const std::exception &exception);

message_box & operator << (message_box & messagebox, const stl::file_exception &exception); // file_exception ist eine von runtime_error abgleitete Klasse

In der main passiert folgendes:

int main()
{
    try
    {
        throw stl::file_exception("test.txt");
    }
    catch(std::exception &ex)
    {
        win::message_box::error << ex;
    }
}

Ich ging davon aus, dass der <<-Operator für file_exceptions aufgerufen wird, das ist aber nicht so. Es wird der für std::exception ohne Template aufgerufen.
Liegt das daran, dass bei der Ausgabe nicht mehr klar ist, dass die exception eigentlich eine file_exception ist? Wenn ja, kann man da irgendetwas gegen machen? Ich will nicht tausende catch-Blöcke haben.
lg
Nathan

Der operator << dient lediglich der Optik.
Ich nutze Streams überall aus optischen Gründen.

Seltsame Leute gibts ...

Tja.
Ich finde das schön.^^

Solange der Code nur für dich selber ist, ist es ja relativ egal. Wenn du dann aber mal mit mehreren Leuten programmierst, dann sollte man sich an gewisse "Normen" halten. Ansonsten sind die Klasse, usw. nutztlos, weil sie sich einfach nur falsch verhalten. Und wenn du jetzt immer so weiter programmierst, dann wirst du immer wieder in diesen Stil zurückfallen und ihn nur schwer verbessern können...

win::message_box::error(e.what());

? Da brauchst du dann auch nur noch std::exception zu fangen..

In welchen Situationen machen Streams/operator << denn wirklich Sinn?

Wenn du tatsächlich Stream-Semantik hast. D.h. du kannst mehrere Objekte hintereinander irgendwo reinschieben. Z.B. in ein Packet, das übers Netzwerk versendet wird. Sinnvoll ist dabei, wenn der operator<< verkettet werden kann, und wenn es möglicherweise auch einen operator>> mit umgekehrter Semantik gibt.

Aber verwende << und >> nicht, wenn benannte Funktionen viel aussagekräftiger sind und man erst mal überlegen muss, was der Operator in deinem Kontext bedeuten könnte.

In welchen Situationen machen Streams/operator << denn wirklich Sinn?

Streams=Datenfluss
http://de.wikipedia.org/wiki/Datenstrom
http://en.wikipedia.org/wiki/Stream_%28computing%29

<< = formatierte Ausgabe

> = formatierte Eingabe

=> Wenn man einen Datenfluss mit formatiertem Text hat.

Für unformatierte Sachen wie Images oder Packets sind Streambuffer zuständig.

Wobei das alles relativ ist, weil sich die Standardbibliothek nicht einmal selber daran hält. Ist ein riesiger Murks, den man am liebsten umgeht (nicht grundlos haben std::exceptions ein what() und kein operator>>).

Für mich ist der Kontext klar und die Operatoren sind lediglich Alternativen zu benannten Funktionen.

Es gibt aber einen grossen semantischen Unterschied.

win::message_box::error << "1";
// Erwartung: error enthält "1"
win::message_box::error << 2 << '3';
// Erwartung: error enthält "123"

win::message_box::error.set_msg("1");
// Erwartung: error enthält "1"
win::message_box::error.set_msg("2"); // nur strings erlaubt
win::message_box::error.set_msg("3");
// Erwartung: error enthält "3"

Wenn du das richtig umsetzen willst, müsste jede Klasse einen stringstream halten und das ist Overkill.

Ausserdem führt dein Ansatz zu Inkonsistenzen

std::deque<int> d;
d << 4 << 5 << 6; // ich bin ganz schlau und habe operator>> überladen
int a, b;
d >> a >> b; // a=4 und b=5 und d.size()=1

d.push_front(3); // leider kein Operator mehr frei
int c = d.back(); d.pop(); // dito

Daher: Im Zweifelsfall lieber benannte Funktionen, die haben Namen und jedem ist klar, was sie machen.

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

Ist es da in Ordnung die Operatoren zu verwenden?

Ich würde zum Zeichnen ebenfalls nicht diese Operatoren verwenden. Was stört dich an

window.draw(sprite1);
window.draw(sprite2);
window.display();

? Hat neben dem besser verständlichen Code auch den Vorteil, dass du mehrere Parameter angeben kannst. Zum Beispiel, wenn du etwas mit einem Shader rendern willst:

window.draw(sprite, shader);

Ich weiß es nicht, mir gefällt das optisch nicht so...

Das ist aber die Syntax für Methodenaufrufe, daran solltest du dich in modernen Sprachen besser gewöhnen.

Davon abgesehen: window.draw(sprite); kannst du lesen als "window draws sprite", expressiver geht gar nicht. Bei << ist es hingegen ein Rätselraten.

Ich werde << und >> nur noch verwenden, wenn der Stream von i/ostream abgeleitet ist/werden kann.

Es gibt schon auch andere Fälle, wo es sinnvoll sein kann. Aber die Semantik ist üblicherweise sehr ähnlich zu Streams.

Beispiel ist die Klasse sf::Packet von SFML. Diese repräsentiert ein Netzwerkpaket, wobei << und >> Werte ein- und auslesen.

optiker schrieb:

Ausserdem führt dein Ansatz zu Inkonsistenzen

Bei Streams gibt es aber keine? Deswegen kann ich auch so toll Binärdaten mittels operator>> einlesen?
Ich habe noch nie die vorparsenden Einlesefunktionen benutzt, denn das haut nur einigermaßen hin, wenn man die Eingabe spezifisch auf sie abstimmt …

Nexus schrieb:

Davon abgesehen: window.draw(sprite); kannst du lesen als "window draws sprite"

Ist es nicht eher eine Anweisung, also ein Befehl, keine Aussage? (Vgl.: window, draw sprite)