sprintf in C++

[lurker]

volkard schrieb:

...

sorry, aber dein ständiger sarkasmus und deine arroganz sind echt ätzend.
sollte ein moderator nicht ein bisschen mehr soziale kompetenz vorweisen können?

[Dravere]

volkard schrieb:

Dravere schrieb:

Würdest du mir erklären, wie die Internationalisierung mit sprintf leichter geht?

wozu? keiner sagte, man müsse immer und unter allen umständen printf nehmen. für natürliche zahlen als teil von dateinamen verzichte ich sogar gelegentlich auf die internationalisierung.

1. War die Frage nicht an dich gerichtet!
2. War die Frage ernst gemeint, da ich selber hingeschrieben habe, dass mir in dem Bereich noch Wissen fehlt. Mich würde das Thema also interessieren, ich habe höflich nach Informationen gebeten.
3. Ist deine Antwort dadurch echt ein wenig daneben!

Grüssli

[~fricky]

It0101 schrieb:

J
Ich oute mich hiermit auch mal als gelegentlicher Verwender von C-Funktionen.

welch harter schlag ins gesicht derer, die jahrelang für den erhalt der guten sitten in der c++ community gekämpft haben.

[It0101]

Ist sowieso sinnlos, dass ihr euch zofft. Auch in dem anderen Thread.

Ihr seid eben unterschiedlicher Meinung... Jeder glaubt die Wahrheit für sich gepachtet zu haben, aber wie immer liegt die wohl irgendwo dazwischen.

[dooooomi]

Dravere schrieb:

audacia schrieb:

Außerdem ist es ein gewaltiger PITA, einen mit Stringstreams formatierten String zu internationalisieren.

Würdest du mir erklären, wie die Internationalisierung mit sprintf leichter geht?

Mit printf() etc. hast du in den meisten Fällen einen kompletten, zusammenhängenden String, den du als ganzes übersetzen kannst. Bei Streams ist das nicht der Fall, da einzelne Bruchstücke von Strings immer wieder von Variablen und ähnlichem unterbrochen werden.

Aber das ist natürlich kein Grund, printf() zu benutzen, sondern spricht eher für Boost.Format oder vergleichbare Lösungen, zumal die Internationalisierbarkeit auch mit printf() o.ä. leicht an ihre Grenzen stoßen kann.

[asc]

dooooomi schrieb:

Aber das ist natürlich kein Grund, printf() zu benutzen, sondern spricht eher für Boost.Format oder vergleichbare Lösungen, zumal die Internationalisierbarkeit auch mit printf() o.ä. leicht an ihre Grenzen stoßen kann.

Platzhalter für I18N sind ohnehin recht schnell am Ende ihrer Grenzen, womit sowohl alle C-Funktionen, boost::format sowie streams Probleme haben. Kleines Beispiel: Internationale Adressen.

Je nach Anwendungsfall kann es sinnvoll sein Einzelbestandteile der Adresse für die Eingabe und Auswertung zu trennen. Und je nach Adressaufbau gehören die Einzelbestandteile in grundsätzlich anderer Reihenfolge wieder zusammengesetzt.

Hier spricht ein Teil sogar für eine partielle Verwendung von Streams. So könnte man für eine Adresse die Streamoperation definieren, um diese abhängig von dem Aufbau intern zusammenzusetzen (Intern kann dann boost::format etc. teilweise sinnvoll sein, insgesamt ist dann der Stream aber eine benutzerfreundliche Möglichkeit für den Anwender die Ausgabe des Adress-Objektes zu realisieren).

Auch einfache Texte lassen sich teilweise nicht mittels einfachen Platzhalter internationalisieren. Weil je nach Sprache manche Sachen in der einen Sprache ein Wort, in der nächsten mehrere (die noch dazu an anderen Positionen stehen können) sind.

cu André

[Dravere]

dooooomi schrieb:

Mit printf() etc. hast du in den meisten Fällen einen kompletten, zusammenhängenden String, den du als ganzes übersetzen kannst. Bei Streams ist das nicht der Fall, da einzelne Bruchstücke von Strings immer wieder von Variablen und ähnlichem unterbrochen werden.

Achso, danke. Daran hatte ich gar nicht gedacht.
Allerdings war es auch nicht gerade das, was mir bei Internationnalisierung als erstes in den Sinn kommt. Wahrscheinlich habe ich mich darüber noch zu wenig geärgert
Da erscheint mir aber Boost.Format doch eher das richtigere zu sein. Werd ich mir merken.

@It0101,
Klappe! Du bist noch von C besessen, hast hier nichts zu sagen. ...
(Ich möchte zur Sicherheit anmerken, dass der Satz wirklich als Witz gemeint war und auf keinen Fall ernst zu nehmen ist ;))

Ich sehe das nicht als Zoff an, ich sehe das eher als eine interessante Diskussion. Mag sein, dass ich hitzig werde, zittrige Hände bekomme und meine Atmung sich beschleunigt oder flacher wird, aber das empfinde ich als ganz normal bei einer guten Diskussion, wo es zur Sache geht

Das einzige was mich zum Beispiel bei volkard bisher gestört hat, ist sein Sarkasmus. Das mag ich nicht unbedingt in Diskussionen, da dies schnell mal beleidigend wirken kann.
Ansonsten habe ich bisher einfach gemerkt, dass wir ein wenig verschieden denken, aber das ist ja normal unter den Menschen.

Grüssli

[audacia]

Dravere schrieb:

audacia schrieb:

... in der Praxis sind sie deutlich langsamer, ...

Inwiefern langsamer? Testberichte? Puffer gesetzt? Oder meinst du umständlicher zu schreiben?

Bezogen auf die Stringstreams kann ich das nicht sagen, da ich sie nicht benutze (Volkard scheint das getestet zu haben). Mit C++-Dateistreams hatte ich allerdings schon erschreckende Erfahrungen; an einem guten Teil davon war zwar das Zusammenspiel der Dinkumware-Standard-Library (die sich auf massive Optimierungen verläßt) und BCC (der nicht allzuviele beherrscht) schuld, aber auch bei MSVC hatte ich noch einen spürbaren Unterschied zu Dateioperationen mit C- oder Win32-Dateistreams.

Dravere schrieb:

Ich würde sie als "komplexer gebaut" bezeichnen. Sie bieten dafür viel mehr Möglichkeiten als nur zum Beispiel ein sprintf .

Freilich. Die Frage ist, ob man die ganze Erweiterbarkeit braucht, oder ob es nicht doch sinnvoller ist, einer Klasse eine toString()-Methode zu verpassen, anstelle die Streamoperatoren dafür zu überladen. In der Praxis erweist sich das meiner Erfahrung nach als lesbarer und intuitiver.

dooooomi schrieb:

Aber das ist natürlich kein Grund, printf() zu benutzen

Doch. Natürlich ist boost::format vorzuziehen - aber ein guter Grund für die Verwendung von sprintf() ist das trotzdem.

[asc]

audacia schrieb:

Bezogen auf die Stringstreams kann ich das nicht sagen, da ich sie nicht benutze (Volkard scheint das getestet zu haben). Mit C++-Dateistreams hatte ich allerdings schon erschreckende Erfahrungen; an einem guten Teil davon war zwar das Zusammenspiel der Dinkumware-Standard-Library (die sich auf massive Optimierungen verläßt) und BCC (der nicht allzuviele beherrscht) schuld, aber auch bei MSVC hatte ich noch einen spürbaren Unterschied zu Dateioperationen mit C- oder Win32-Dateistreams.

Ich kann dir nur sagen das, wenn man a) Buffer setzt (die ja leider bei den Streams meist nicht gesetzt sind, bei den C-Funktionen schon) und b) irgendwelche Zusatzprüfungen des Compilers deaktiviert (z.B. in MSVC SCL_SECURE oder wie der wieder heißt), die Performance nahezu identisch ist (zumindestens unter den Compilern die ich getestet habe).

cu André

[hallo gehts noch]

audacia schrieb:

Freilich. Die Frage ist, ob man die ganze Erweiterbarkeit braucht, oder ob es nicht doch sinnvoller ist, einer Klasse eine toString()-Methode zu verpassen, anstelle die Streamoperatoren dafür zu überladen. In der Praxis erweist sich das meiner Erfahrung nach als lesbarer und intuitiver.

Das würde ja garnicht mehr C++-stylisch-pro-mäsig aussehen und jeder anfänger könnte das.

[Shade Of Mine]

hallo gehts noch schrieb:

audacia schrieb:

Freilich. Die Frage ist, ob man die ganze Erweiterbarkeit braucht, oder ob es nicht doch sinnvoller ist, einer Klasse eine toString()-Methode zu verpassen, anstelle die Streamoperatoren dafür zu überladen. In der Praxis erweist sich das meiner Erfahrung nach als lesbarer und intuitiver.

Das würde ja garnicht mehr C++-stylisch-pro-mäsig aussehen und jeder anfänger könnte das.

nur ein Wort: iomanip

deshalb ist toString() in C++ eine sehr sehr dumme Loesung.

[hallo gehts]

Shade Of Mine schrieb:

hallo gehts noch schrieb:

audacia schrieb:

Freilich. Die Frage ist, ob man die ganze Erweiterbarkeit braucht, oder ob es nicht doch sinnvoller ist, einer Klasse eine toString()-Methode zu verpassen, anstelle die Streamoperatoren dafür zu überladen. In der Praxis erweist sich das meiner Erfahrung nach als lesbarer und intuitiver.

Das würde ja garnicht mehr C++-stylisch-pro-mäsig aussehen und jeder anfänger könnte das.

nur ein Wort: iomanip

deshalb ist toString() in C++ eine sehr sehr dumme Loesung.

Warum? Kann man irgendwas in ner normalen Methode nicht machen, was man in nem überladenen Operator machen kann? Überladene Methoden sind doch auch nur Methodenaufrufe mit etwas anderer Syntax.

[hallo gehts@edit]

Warum? Kann man irgendwas in ner normalen Methode nicht machen, was man in nem überladenen Operator machen kann? Überladene Operatoren sind doch auch nur Methodenaufrufe mit etwas anderer Syntax.

[volkard]

Shade Of Mine schrieb:

nur ein Wort: iomanip

waren das nicht die tollen manipulatoren für streams?

damit kann man dann endlich

cout << setw(4) << iVal;
  cout << "  0x" << hex << uppercase << setprecision(2) << setfill('0') << setw(2) << hVal;
  cout << setfill(' ') << dec; // reset things
  cout << "  Testfile: [" << setw(10) << filename << "]";
  cout << "  user: [" << setw(10) << left << username << right << "]";
  cout << "\n";
  cout << "Trial " << setw(8) << fixed << setprecision(2) << fValue;
  cout << endl;

schreiben statt

printf("%4d  0x%02X  Testfile: [%10s]  user: [%-10s]\nTrial %8.2f \n",
      iVal, hVal, filename, username, fValue);

ja, die haben ein problem nit ToString(). deswegen bieten solche sprachen für zahlen gleich auch ein Format() an, anstatt es gleich hübsch zu machen.

(code geliehen von http://www.daniweb.com/forums/thread73939.html )

[hallo gehts]

Wirklich toll ist das was man mit iomanip machen kann ja auch nicht, gerade mal ein bisschen Zahlen formatieren. Und konsistent ist das ganze auch nicht. Wenn man was mit Zeit und Datum machen will, braucht man zusätzlich time_put facet, weil da das was am stream mit iomanip hängt nicht viel bringt. Für alles irgendwelche iomanip oder ähnliches am stream kleben zu haben ist natürlich auch zuviel. Da find ich für einfache Texte toString und für Formatierung dann Number- oder DateFormat schon konsistenter.

Kann eigentlich printf number und date format mit internationalisierung ohne zusätzliche "externe" funktionen, also nur mit "%d9.4..." zeugs?

[asc]

hallo gehts schrieb:

Kann eigentlich printf number und date format mit internationalisierung ohne zusätzliche "externe" funktionen, also nur mit "%d9.4..." zeugs?

Nein.

Davon abgesehen gibt es dennoch bessere Alternativen zu der printf-Familie, auch für die, die keine Streams mögen. Siehe z.B. boost::format.

[Shade Of Mine]

volkard schrieb:

waren das nicht die tollen manipulatoren für streams?

Um ehrlich zu sein, ich habe noch kein schoenes System fuer Formatspezifizierungen gefunden.

Die printf-Syntax hat zB als Vorteil die kompaktheit und ist oft eine gute Wahl fuer simple Sachen. Fuer komplexe Sachen muss man oefters mal in eine Doku sehen.

Die iomanip sind leichter verstaendlich aber aetzend einzusetzen.

Die C# Methode mit der eigenen Klasse fuer die String Formatierung.

Alles irgendwie nicht wirklich schoen

[volkard]

Shade Of Mine schrieb:

Um ehrlich zu sein, ich habe noch kein schoenes System fuer Formatspezifizierungen gefunden.
[...]
Alles irgendwie nicht wirklich schoen

jup, jetzt isses ausgesprochen worden.

[Nexus]

Wie sähe denn euer Ideal aus?

[volkard]

Nexus schrieb:

Wie sähe denn euer Ideal aus?

ich bin zu dumm, um es zu finden. und viele andere auch, scheint mir. vielleicht gibt es keine angenehme lösung. vielleicht erfindet in dieser minute jemand was tolles. vielleicht erst in 81 jahren und ich darf es nicht mehr erleben.