Allgemeine Frage, betreffs "printf" und "cout"

[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

[Simon2]

pale dog schrieb:

....
- cout macht falsche ausgaben, wenn variablen als 'volatile' deklariert sind.
- bei cout muss man manchmal 'endl' o.ä. dranhängen, sonst wird nix ausgegeben.

aber im grunde genommen ist es egal, welches man benutzt.

Ersteres nur, wenn man seine Compiler-Warnungen ignoriert und Zweiteres leuchtet mir gar nicht ein: Warum sollten printf() und cout unterschiedlichen flushing-Strategien haben (und warum soillte ein "schnelles flush" automatisch besser sein) ?
Die "einfachere Benutzung für bestimmte Formatierungen" (die ich auch so sehe) muss man eben gegen die Typsicherheit (inkl. Readoverflows) und die (IMO) weniger kryptischen Formatierungsmöglichkeiten abwägen....

Gruß,

Simon2.

[Simon2]

thordk schrieb:

...

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

Mach das mal mit einem 5mal so langen Ausdruck !
Die Operatorsyntax (sei es nun <<>> oder was auch immer) hat nunmal den Vorteil, eine Quelltextstrukturierung whitespaces zu erlauben, was mit "." nicht geht.

Gruß,

Simon2.

[Konrad Rudolph]

Simon2 schrieb:

ie Operatorsyntax (sei es nun <<>> oder was auch immer) hat nunmal den Vorteil, eine Quelltextstrukturierung whitespaces zu erlauben, was mit "." nicht geht.

Doch

ich. kann().
     meine()   .c_operatoren() -> formatieren, wie( ich ).lustig . bin;

[Simon2]

Konrad Rudolph schrieb:

Simon2 schrieb:

ie Operatorsyntax (sei es nun <<>> oder was auch immer) hat nunmal den Vorteil, eine Quelltextstrukturierung whitespaces zu erlauben, was mit "." nicht geht.

Doch

ich. kann().
     meine()   .c_operatoren() -> formatieren, wie( ich ).lustig . bin;

Also das war mir neu !
OK, ich ziehe meinen Einwand zurück .... und finde immer noch die Operatoren "hübscher".

Gruß,

Simon2.

[tntnet]

pale dog schrieb:

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

Ich frage mich, woher dieses Gerücht kommt. C++ ist seit 1998 standardisiert und da wird nicht ständig herumgeschraubt. Die nächste Version ist 2009 zu erwarten. Das sind 11 Jahre, wo sich in C++ nichts geändert hat. Vergleiche das mal mit anderen Sprachen.

Um hier nicht den falschen Eindruck zu hinterlassen: das ist einer der großen Vorteile von C++. Ich muss meine Programme nicht ständig neuen Versionen anpassen.

Und noch was: So sieht das schon lesbarer aus:

cout.append("foobar")
    .setw(5)
    .setprecision(2)    // jetzt passt hier sogar ein Kommentar rein
    .append(3.14f)
    .endl()
    .append("noch ne zeile");

Und das append (oder print) könnte natürlich ein Template sein, welches operator<< aufruft und dadurch erweiterbar wird. Wobei ich die vorhandene Schreibweise bevorzuge. Aber die Formatierung ist mit iostreams problematischer, als mit printf. Deswegen hat man boost.format geschaffen, welches bezüglich Sicherheit klar an printf vorbeizieht.

Ansonsten kann ich mich dem nur anschliessen, daß auch ich schon einige Programme gesehen habe, die an fehlerhaften Formatstrings in printf gescheitert sind. Daher verwende ich kein printf.

[Simon2]

tntnet schrieb:

pale dog schrieb:

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

Ich frage mich, woher dieses Gerücht kommt....

Wahrscheinlich mit Java verwechselt - kann ja mal passieren ...

tntnet schrieb:

...Aber die Formatierung ist mit iostreams problematischer, als mit printf....

Magst Du mal anführen, wieso ?
Was mich bei den Streams stört, ist, dass sie "die Formatierer vergessen" ... oder kann man cout irgendwie "einmalig um- und später wieder zurückstellen" ?

Gruß,

Simon2.

[haha]

MFK schrieb:

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.

Ja, mann kann für die Ausgaben auch Assembler benutzen, oder mit einem Edding sein C++ Hello World auf den Monitor schreiben.

[CStoll]

Simon2 schrieb:

Was mich bei den Streams stört, ist, dass sie "die Formatierer vergessen" ...

Was meinst du mit "Formatierer vergessen"? Das einzige Flag, was nach jeder Ausgabe zurückgesetzt wird, ist die width, alle anderen Angaben bleiben bis auf Widerruf gültig.

oder kann man cout irgendwie "einmalig um- und später wieder zurückstellen" ?

Du kannst dir alle relevanten Formate mit flags(), precision() und fill() aus dem Stream ziehen und später wieder mit den selben Funktionen zurücksetzen. (oder du legst dir einen Dummy-Stream an, der per copyfmt() alle Formate von cout übernimmt)

[Undertaker]

tntnet schrieb:

pale dog schrieb:

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

Ich frage mich, woher dieses Gerücht kommt. C++ ist seit 1998 standardisiert und da wird nicht ständig herumgeschraubt.

für die nächste version sind doch viele erweiterungen geplant.
es war sicher nicht so gemeint, dass bestehendes verändert oder abgeschafft wird.

[asc]

Zu den Änderungen von C++:

Ja, C++ ist Standardisiert (98, Ergänzungen 2003 und wohl 2009 der nächste Standard) und ändert sich sprachlich kaum.

Nein, auch wenn C++ standardisiert ist, ist dennoch eine ständige Entwicklung da. Zwar nicht an der Sprache als solches aber an der Form wie sie eingesetzt wird (Ich sage mal als ein Beispiel Templatemetaprogrammierung).

In dieser Hinsicht erinnert mich C++ an einen Baukasten: Es enthält zwar Standardisierte Bauteile, aber das Verständinis was man daraus alles machen kann wächst erst mit der Zeit. Und dabei entstehen durchaus auch Dinge die die Entwickler des Ganzen garnicht anfangs wahrgenommen haben.

Zudem kommen noch teilweise verkorkste Umsetzung einher, die einen unbedarften immer denken lassen das sich die Sprache ständig ändert (von Compilergeneration zu Compilergeneration findet eine laufende Anpassung an den Standard statt).

cu André

[Simon2]

CStoll schrieb:

Simon2 schrieb:

Was mich bei den Streams stört, ist, dass sie "die Formatierer vergessen" ...

Was meinst du mit "Formatierer vergessen"? Das einzige Flag, was nach jeder Ausgabe zurückgesetzt wird, ist die width, alle anderen Angaben bleiben bis auf Widerruf gültig....

Das ist mir aber noch nie aufgefallen, weil ich bislang IMMER (auch) width() verwendet habe.

Deswegen: Vielen Dank - mal wieder was gelernt.

Gruß,

Simon2.