Allgemeine Frage, betreffs "printf" und "cout"

[pale dog]

bedeutet das, dass in C++ ein

bool b = irgendwas;

eigentlich immer ein

bool b = (irgendwas != 0);

ist?
(wobei 'irgendwas' nicht 0 oder false sein darf)
wenn ja, dann findet doch keine typumwandlung statt.
das würde mich wieder besänftigen, auch wenn 'cout' darunter zu leiden hat

[Konrad Rudolph]

pale dog schrieb:

bedeutet das, dass in C++ ein

bool b = irgendwas;

eigentlich immer ein

bool b = (irgendwas != 0);

ist?
(wobei 'irgendwas' nicht 0 oder false sein darf)
wenn ja, dann findet doch keine typumwandlung statt.

Wenn Du meinst … wie dem auch sei, das Resultat ist dasselbe; nämlich die Umwandlung eines Werts in ein Boolean.

[Krux]

back to Topic.

Ich finde cout wesentlich übersichtlicher und sauberer, als printf, weil es alles in eine Klassenhirachie gepackt hat. Man hat auch die Möglichket durch die übergabe von Manipulatoren, die Ausgabe zu formatieren. Un man kann für seine klassen den << Operator der klasse ostream überschreiben, was später zu einem übersichtlicherem code führt, als würde man sich eine toC_String Methode schreiben, und die dann bei jedem printf aufruf manuell aufrufen. Ja und printf ist C, kann also nicht mit Strings umgehen. Ich finde, wer C++ programmiert, und nicht C, der ist mit cout besser bedient. Ich finde es gibt kaum gründe, weshalb man printf verteidigen sollte, ausser vieleicht die geschwindigkeit, aber die ist ja bei der geringen menge, die auf die Konsole passt ja doch eher unwichtig, man sollte besser schauen, an welchen anderen stellen man sein programm dann optimieren kann.

[btt]

ich finde cout wesentlich lahmerer als printf

[Bashar]

Der eigentliche Witz ist, dass cout schneller sein sollte als printf, weil printf jedesmal den Formatstring interpretiert, während bei IOStreams alles statisch ist.

[The-Kenny]

btt schrieb:

ich finde cout wesentlich lahmerer als printf

Wenn man wegen diesen paar millisekunden auf die Typsicherheit und flexibilität verzichten will....

[Der Typ mit der Frage]

Also ist cout mal abgesehen von der Geschwindigkeit besser als printf?

[MFK]

Der Typ mit der Frage schrieb:

Also ist cout mal abgesehen von der Geschwindigkeit besser als printf?

Nein. So einfach ist das nicht.

Wenn du den Thread liest, sollte doch klar werden, dass viel vom Bewertungsmaßstab und von persönlichen Vorlieben abhängt. Was "besser" ist, kannst du nur für dich selbst definieren. Je nachdem, was dir wichtig ist, könnte auch boost::format "besser" sein.

[Konrad Rudolph]

Der Typ mit der Frage schrieb:

Also ist cout mal abgesehen von der Geschwindigkeit besser als printf?

Hat da eigentlich mal jemand auf unterschiedlichen Systemen Performance-Tests gemacht? Ich kann mir einfach nicht vorstellen, dass 'cout' langsamer als 'printf' sein sollte.

[asc]

Konrad Rudolph schrieb:

Hat da eigentlich mal jemand auf unterschiedlichen Systemen Performance-Tests gemacht? Ich kann mir einfach nicht vorstellen, dass 'cout' langsamer als 'printf' sein sollte.

Ja, haben einige gemacht (einfach mal googlen). Ich habe bislang kein ergebnis gesehen wo cout schneller als printf war, aber je nach System/Compiler waren die mehr oder weniger dicht beieinander (zwischen fast gleich und Faktor 10).

Falls man nach Gründen hierfür sucht sollte man bedenken das printf schon deutlich länger existiert, und demzufolge deutlich optimierter sein kann. Wenn die Streambehandlung auf den gleichen Stand wäre, hätte cout vermutlich die Nase vorn.

Die Frage ist hierbei aber was ist einem wichtiger, und wie relevant ist in diesem Fall der zeitliche Unterschied.

printf vs. cout
1:0 Geschwindigkeit
2:0 Lesbarkeit
2:1 Erweiterbarkeit
2:2 Sicherheit

Vor allem das allerletzte Argument ist mir sehr wichtig, ich habe schon mehr als ein Programm dank printf (und vergleichbaren) Abrauchen gesehen weil ein Argument zu wenig oder falsch übergeben wurde. Ich ziehe manchmal sogar boost::format in Betracht obwohl es noch langsamer ist...

cu André

[otze]

//edit 2 ha, doch noch was zum schreiben gefunden, da kriegt der post doch noch nen Sinn.

@asc ich finde aber die streamschreibweise für ausgabenw esentlich schöner und einfacher zu lesen als die komischen formatstrings mit nachfolgenden argumenten. kommt wohl echt drauf an, was man gewohnt ist.

[CStoll]

asc schrieb:

printf vs. cout
1:0 Geschwindigkeit

Das ist alles eine Frage der Umsetzung - beide haben das gleiche Potential zur Geschwindigkeit (und IOStream-Operatoren den potentiellen Vorteil, daß sie sich besser spezialisieren können).

2:0 Lesbarkeit

Bestimmt nicht - der Aufbau des Formatstrings ist wesentlich undurchsichtiger als die Formatierungsmöglichkeiten von cout

2:1 Erweiterbarkeit
2:2 Sicherheit

Die beiden Punkte sind dagegen klar verdient (besonders letzterer) - obwohl das Anlegen eines guten IO-Operators auch nicht gerade trivial ist

[asc]

CStoll schrieb:

...Das ist alles eine Frage der Umsetzung...

Von dem Potential habe ich ja auch schon geredet, nur derzeit mangelt es an der entsprechenden Umsetzung (unter VC++ scheint dies noch mehr zuzutreffen als unter vielen anderen Compilern). Und die Lesbarkeit ist relativ, wenn man nicht ständig irgendwelche Flags setzen muss sind beide etwa gleich, nur spätestens bei komplexen Formatierungen ist cout imho etwas im Nachteil.

Mich brauchst du zum Glück auch nicht von Streams überzeugen, ich ziehe sie den c-Funktionen eh vor.

cu André

[CStoll]

asc schrieb:

Und die Lesbarkeit ist relativ, wenn man nicht ständig irgendwelche Flags setzen muss sind beide etwa gleich, nur spätestens bei komplexen Formatierungen ist cout imho etwas im Nachteil.

Also ich finde Angaben wie cout<<setw(5)<<setprecision(3)<<value; wesentlich lesbarer als printf("%5.3f",value); (auch wenn ersteres die Tendenz hat, sich in die Länge zu ziehen) - aber das ist wohl Geschmackssache. Vor allem muß man viele Formate beim Stream nur einmal setzen und sie gelten anschließend bis auf Widerruf für ALLE Ausgaben.

[thordk]

das einzige, was mich an streams stört ist... naja, dass es streams sind :p die vorteile sind unbestritten, aber diese ganzen << und >> im code, die keine bit-shifts, sondern streams sind, find ich eklig

[Konrad Rudolph]

thordk schrieb:

das einzige, was mich an streams stört ist... naja, dass es streams sind :p die vorteile sind unbestritten, aber diese ganzen << und >> im code, die keine bit-shifts, sondern streams sind, find ich eklig

Mit anderen Worten, Dich stört die Syntax. Denn 'printf' wird wohl genauso Streams verwenden.

Abgesehen davon finde ich die Notation mit dem '<<' überhaupt nicht so schlimm, wie immer wieder behauptet wird. Das ganze ist eine konzise Art auszudrücken, dass mit Strömen operiert wird. Ich erwarte immer noch, dass jemand einen besseren Vorschlag macht. '+=' finde ich hierbei z.b. extrem schlecht geeignet.

[CStoll]

thordk schrieb:

aber diese ganzen << und >> im code, die keine bit-shifts, sondern streams sind, find ich eklig

Und ich finde die kryptischen Formatkennungen, die man für printf() benötigt (und die damit verbundenen Inkonsistenzen), eklig

[thordk]

Konrad Rudolph schrieb:

thordk schrieb:

das einzige, was mich an streams stört ist... naja, dass es streams sind :p die vorteile sind unbestritten, aber diese ganzen << und >> im code, die keine bit-shifts, sondern streams sind, find ich eklig

Ich erwarte immer noch, dass jemand einen besseren Vorschlag macht. '+=' finde ich hierbei z.b. extrem schlecht geeignet.

cout.append("foobar").setw(5).setprecision(2).append(3.14f).endl().append("noch ne zeile");

[CStoll]

Ja, das wäre eine Möglichkeit - aber anstelle von append() würde ich eher 'print()' (bzw. für Eingaben 'read()') verwenden. Allerdings hat sowas den Nachteil, daß es nicht erweiterbar ist (operator<< kannst du global definieren, um eigene Typen per append() bzw. print() ausgeben zu können, mußt du die Klasse basic_ostream umbauen).

[Konrad Rudolph]

thordk schrieb:

Konrad Rudolph schrieb:

thordk schrieb:

das einzige, was mich an streams stört ist... naja, dass es streams sind :p die vorteile sind unbestritten, aber diese ganzen << und >> im code, die keine bit-shifts, sondern streams sind, find ich eklig

Ich erwarte immer noch, dass jemand einen besseren Vorschlag macht. '+=' finde ich hierbei z.b. extrem schlecht geeignet.

cout.append("foobar").setw(5).setprecision(2).append(3.14f).endl().append("noch ne zeile");

Java lässt grüßen. Genau für solche Zwecke (Verkettung vieler Operationen) sind Operatoren nunmal ideal geeignet. Ich finde Deinen Code wesentlich unübersichtlicher als die Verwendung eines arbiträren Operators. Von den Problemen, die CStoll aufgezeigt hat, ganz zu schweigen.

Ich sollte hier vielleicht darauf hinweisen, dass ich die Lösung über '<<' auch nicht ideal finde. Generell bevorzuge ich z.B. die Boost-format-Variante. Es stellt sich eben die Frage, ob man durch die Syntax überhaupt klarmachen muss, dass man auf einen Stream zugreift. Aber auch die Boost-format-Variante überlädt einen Operator und ihm eine (nicht ganz) neue Semantik, zumindest im Kontext von C++ (Perl z.B. kennt etwas ähnliches).

Generell finde ich es aber *nicht* schlimm, Operatoren eine neue Semantik zu verpassen, wie es hier geschehen ist. Das Argument, dass man hier eine Bit-Shift-Operation erwartet, kann ich nicht nachvollziehen. Solange man ein wenig Vorsicht walten lässt und Operatoren nicht offensichtlich sinnlose oder widersprüchliche Semantiken verpasst, ist das überhaupt kein Problem.