Allgemeine Frage, betreffs "printf" und "cout"

[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.

[pale dog]

Konrad Rudolph schrieb:

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

finde ich auch: man sollte dafür ein neues token erfinden, da << und >> ja schon anderweitig belegt sind, und zu verwechselungen führen können.
-> ist leider auch schon vergeben.
vielleicht >>> und <<< ?
das scheint mir aber auch nicht optimal, die cout/cin zeilen würden dadurch noch länglicher werden.

Konrad Rudolph schrieb:

Generell bevorzuge ich z.B. die Boost-format-Variante.

also doch 'printf'

[David_pb]

pale dog schrieb:

Konrad Rudolph schrieb:

Generell bevorzuge ich z.B. die Boost-format-Variante.

also doch 'printf'

Boost-Format verwendet kein printf!

[CStoll]

pale dog schrieb:

Konrad Rudolph schrieb:

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

finde ich auch: man sollte dafür ein neues token erfinden, da << und >> ja schon anderweitig belegt sind, und zu verwechselungen führen können.
-> ist leider auch schon vergeben.
vielleicht >>> und <<< ?
das scheint mir aber auch nicht optimal, die cout/cin zeilen würden dadurch noch länglicher werden.

Dagegen sprechen allerdings die natürlichen Beschränkungen der Sprache - du kannst bestehende Operatoren für eigene Typen überladen, aber du kannst weder neue Operatoren definieren noch die Rangfolge etc. der Operatoren beeinflussen. Das heißt, wenn du einen Stream-Operator auswählen willst, bist du auf das vorhandene Sortiment beschränkt.

[pale dog]

David_pb schrieb:

Boost-Format verwendet kein printf!

aber 'ne ähnliche syntax wie die printf formatstrings

[David_pb]

Naja, "ähnlich". Aber dafür Typensicher!

[pale dog]

CStoll schrieb:

pale dog schrieb:

Konrad Rudolph schrieb:

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

finde ich auch: man sollte dafür ein neues token erfinden, da << und >> ja schon anderweitig belegt sind, und zu verwechselungen führen können.
-> ist leider auch schon vergeben.
vielleicht >>> und <<< ?
das scheint mir aber auch nicht optimal, die cout/cin zeilen würden dadurch noch länglicher werden.

Dagegen sprechen allerdings die natürlichen Beschränkungen der Sprache - du kannst bestehende Operatoren für eigene Typen überladen, aber du kannst weder neue Operatoren definieren noch die Rangfolge etc. der Operatoren beeinflussen. Das heißt, wenn du einen Stream-Operator auswählen willst, bist du auf das vorhandene Sortiment beschränkt.

ach, mist, das hab' ich übersehen.
also: sprache erweitern, so dass selbstdefinierte operatoren möglich sind

[Konrad Rudolph]

pale dog schrieb:

ach, mist, das hab' ich übersehen.
also: sprache erweitern, so dass selbstdefinierte operatoren möglich sind

Vollkommen überflüssig. Wie ich bereits sagte: Es spricht IMHO nichts dagegen (einige Sorgfalt vorausgesetzt), bestehende Operatoren mit einer neuen Semantik zu belegen.

/EDIT: Und zu Boost.Format: Finde ich zwar gut, die 'printf'-ähnliche Format-Syntax finde ich hingegen furchtbar. Die .NET-Lösung ist hier z.B. angenehmer.

[pale dog]

Konrad Rudolph schrieb:

pale dog schrieb:

ach, mist, das hab' ich übersehen.
also: sprache erweitern, so dass selbstdefinierte operatoren möglich sind

Vollkommen überflüssig.

an C++ wird doch sowieso ständig herumgeschraubt. wer weiss, vielleicht kommt sowas mal.

Konrad Rudolph schrieb:

/EDIT: Und zu Boost.Format: Finde ich zwar gut, die 'printf'-ähnliche Format-Syntax finde ich hingegen furchtbar. Die .NET-Lösung ist hier z.B. angenehmer.

printf-syntax ist doch gar nicht so kryptisch. schau dir mal 'regular expressions' an, dann weisst du, was schlimm ist

btw: je mächtiger/universeller etwas ist, desto komplizierter wird es. das scheint ein naturgesetz zu sein. auf programmiersprachen-kram trifft es jedenfalls zu...

[Konrad Rudolph]

pale dog schrieb:

Konrad Rudolph schrieb:

pale dog schrieb:

ach, mist, das hab' ich übersehen.
also: sprache erweitern, so dass selbstdefinierte operatoren möglich sind

Vollkommen überflüssig.

an C++ wird doch sowieso ständig herumgeschraubt. wer weiss, vielleicht kommt sowas mal.

Aufgrund der damit verbundenen technischen Probleme relativ unwahrscheinlich.

printf-syntax ist doch gar nicht so kryptisch. schau dir mal 'regular expressions' an, dann weisst du, was schlimm ist

Also, in aller Bescheidenheit möchte ich mal behaupten, dass ich reguläre Ausdrücke flüssig lesen und schreiben kann, und zwar wahrscheinlich besser als die meisten Perl-Programmierer. Aber Du vergleichst hier Äpfel mit Birnen. Reguläre Ausdrücke sind eine eigenständige, extrem mächtige Sprache. Diese Mächtigkeit ist bei der Stringformatierung überhaupt nicht nötig. Abgesehen davon sind die .NET-Formatstrings wesentlich mächtiger als die von C-'printf' und sie sind trotzdem lesbarer.

btw: je mächtiger/universeller etwas ist, desto komplizierter wird es. das scheint ein naturgesetz zu sein.

Das scheint falsch zu sein, wenn man sich die Physik anschaut. Immerhin lassen sich sehr allgemeine Zusammenhänge in sehr einfachen Formeln ausdrücken. Aber das gehört nicht hierher.

[thordk]

Konrad Rudolph schrieb:

Java lässt grüßen.

merkt man, oder? *G bin beruflich bedingt wieder auf java umgestiegen. nach paar jahren c++ wars ne recht harte umgewöhnung, aber man merkt doch, dass bei java wert auf eine sehr saubere und klare strukturierung gelegt wurde. kann c++ nur gut tun