Formatierung in C++

[c++fan 2008]

t.schubert schrieb:

gibt es in C++ eine andere Mgl.keit als sprintf(...), um z. B. einen Float-Wert zu formatieren?

Es gibt stringstream http://www.cplusplus.com/reference/iostream/stringstream/
Aber warum willst du sprintf nicht benutzen?

[asc]

c++fan 2008 schrieb:

Aber warum willst du sprintf nicht benutzen?

Ich wüsste eine Menge Gründe, beginnend mit Typunsicherheit...
Edit: Zumal mich verwundert wie einer der sich "C++Fan" nennt, hinterfragt warum man die C-Bibliothek nicht verwenden will...

[c++fan 2008]

asc schrieb:

Edit: Zumal mich verwundert wie einer der sich "C++Fan" nennt, hinterfragt warum man die C-Bibliothek nicht verwenden will...

Weil er schon eine Möglichkeit zur Formatierung kennt. Für einfache Dinge wie float ist sprintf ausreichend.

[LordJaxom]

c++fan 2008 schrieb:

Weil er schon eine Möglichkeit zur Formatierung kennt. Für einfache Dinge wie float ist sprintf ausreichend.

Bei einfachen Dingen kann man sich genauso Probleme einhandeln wie bei komplexen :p

float f;
sprintf(x, "%lf", f); // ups, schon verkehrt

[Dravere]

c++fan 2008 schrieb:

Weil er schon eine Möglichkeit zur Formatierung kennt. Für einfache Dinge wie float ist sprintf ausreichend.

`

sprintfist nicht für C++ Mittel geeignet.sprintfkann zum Beispiel nicht mit einemstd::stringzusammen verwenden. Also müsste man über einen Charpuffer ausweichen, was völlig unsinnig und kompliziert ist.std::stringstreamübernimmt für einem die Puffergrössen und bietet eine nahtlose Schnittstelle fürstd::string` an.

Grüssli

[c++fan 2008]

Dravere schrieb:

c++fan 2008 schrieb:

Weil er schon eine Möglichkeit zur Formatierung kennt. Für einfache Dinge wie float ist sprintf ausreichend.

`

sprintfist nicht für C++ Mittel geeignet.sprintfkann zum Beispiel nicht mit einemstd::stringzusammen verwenden. Also müsste man über einen Charpuffer ausweichen, was völlig unsinnig und kompliziert ist.std::stringstreamübernimmt für einem die Puffergrössen und bietet eine nahtlose Schnittstelle fürstd::string` an.

Wir wissen nicht was er mit dem formatierten Wert vor hat. Braucht er ihn als nullterminiertes char Array, dann halte ich sprintf für die einfachste Lösung.

[pumuckl]

braucht er ein nullterminiertes char-array, dann sollte er um beim Standard zu bleiben stringstream benutzen und dann mit str() und c_str() den entsprechenden nullterminierten C-String holen.
Oder was zwar deprecated aber immenroch standard ist strstream benutzen. Hat immernoch Typsicherheit und ist sicherer in der Speicherbenutzung.
Oder wenn er denn doch Richtung C-Funktionen gehen will dann snprintf(). Da hat er dann die gleiche Formatsyntax, heißt Tippfehler und Typfehler und die resultierenden Überraschungen zur Laufzeit willkommen. Zwar ist das dann nicht im Standard, ist aber auf den meisten Compilern implementiert und bietet immernoch eine gewisse Sicherheit bezüglich Speicherzugriffsfehler.
sprintf() ist was sowas angeht wirklich die letzte Wahl in C++ (schonmal nach ner überschriebenen Rücksprungadresse gesucht die nur im Releasemodus vorkommt?)

[c++fan 2008]

pumuckl schrieb:

Typsicherheit...Tippfehler...Typfehler...Sicherheit...Speicherzugriffsfehler.

Ich finde dass du diese Dinge überbewertest.

[-C-FAN]

ich finde das du dich eher -C-Fan nennen solltest.

[c++fan 2008]

-C-FAN schrieb:

ich finde das du dich eher -C-Fan nennen solltest.

Nein. Ich programmiere in C++ weil ich Power will. Wenn Sicherheit an erster Stelle steht, sollte man Ada oder eine Skriptsprache wie Java nehmen.

[t.schubert]

Hallo,

ich hätte gar nicht gedacht, dass ich mit meiner Anfrage so eine Diskussion in Gang setze ... Sehr interessant, da merkt man, das in diesem Forum wirklich was passiert.

Zur Sache :

Ich habe bei meiner Anfrage den Grund nicht genannt, mein Fehler.
Die Sache ist eigentlich relativ trivial :
Ich bekomme in relativ kurzer Zeit ein sehr grosses Datenvolumen von Gleitkommazahlen in einem Array übergeben (die zugrundliegende Bibliothek ist eine reine C - Bibliothek, daran kann ich nichts ändern).
Diese Werte sind mitunder von der Anzahl der Nachkommastellen völlig nutzlos
(Werte wie 3.12567890), da ich nur zwei Nachkommastellen benötige.
Somit muss ich diese Werte erst einmal in ein brauchbares Format bringen, dann müssen diese Werte als Strings gespeichert werden (definierte Anforderung).
Da es sich um sehr viele Werte handelt, muss dieser ganze Lese- und Formatiervorgang möglichst zeitlich sehr optimiert sein, d.h. x ms sind hier eine Menge Zeit.
Meine Tests haben ergeben, dass Stringstream deutlich langsamer ist als printf.
Da ich die Werte letzten Endes aber als "echte" C++ - Strings in einem Vektor ablegen möchte kann ich printf dort nicht wirklich nehmen (dann läuft wieder auf c_str() zur Konvertierung in C- Strings hinaus).
Und somit habe ich halt dasProblem, dass es einerseits schnell gehen muss und anderenseits zu std::string passen muss.

vielen Dank :xmas1:

[pumuckl]

c++fan 2008 schrieb:

Ich finde dass du diese Dinge überbewertest.

Wenn du mal mehrere Stunden damit zugebracht hast nach einem Fehler zu suchen der genau aus diesen ekelhaften Eigenschaften von sprintf entstanden ist, dann weißt du diese Dinge auch zu schätzen...

t.schubert schrieb:

Meine Tests haben ergeben, dass Stringstream deutlich langsamer ist als printf.

Das ist auch davon abhängig, wie du den Stringstream verwendest. Objektkonstruktion und die damit zusammenhängende Speicherreservierung ist häufig recht kostspielig. Optimierungen des Compilers können da zwar schon einiges beheben, aber ich würds in dem Fall nicht drauf ankommen lassen, wenn dir dein Profiler schon gesagt hat dass da ein Engpass ist.

[Simon2]

cfan 2008 schrieb:

...Nein. Ich programmiere in C weil ich Power will...

Ist ja auch in Ordnung. Will Dir ja hier keiner was....

Gruß,

Simon2.

[Simon2]

t.schubert schrieb:

...
Meine Tests haben ergeben, dass Stringstream deutlich langsamer ist als printf....

Macht ja auch etwas Anderes (-> "Äpfel/Birnen").
Genauso könntest Du sagen: "Meine Tests haben ergeben, dass ich mit einer Rolltreppe viel später im Erdgeschoss bin als wenn ich springe."

Gruß,

Simon2.

[asc]

t.schubert schrieb:

Meine Tests haben ergeben, dass Stringstream deutlich langsamer ist als printf.

Es gibt auch recht langsame Implementierungen. Falls du z.B. Visual Studio einsetzt gab es dazu (ich glaube im Compilerforum) vor schätzungsweise 2 Monaten einen Thread. Die MS-Umsetzung der Streams ist leider wirklich nicht die Schnellste langsam, am schluß des Threads wurde aber auch eine Lösung genannt.

cu André

[_matze]

asc schrieb:

Die MS-Umsetzung der Streams ist leider wirklich nicht die Schnellste langsam, [...]

Da hattest du wohl mehr Ideen zur Formulierung, als du Sätze schreiben wolltest, was?

[t.schubert]

Ich denke, eine Funktion wie "FloatToStr" wäre gut.
Gibt es ja in Borland bzw. in MS Visual als "ToString".
Dann noch wie gewünscht runden bzw. abschneiden und fertig.

[Simon2]

t.schubert schrieb:

Ich denke, eine Funktion wie "FloatToStr" wäre gut.
Gibt es ja in Borland bzw. in MS Visual als "ToString".
Dann noch wie gewünscht runden bzw. abschneiden und fertig.

Einerseits übernimmt sowas overloading (also reicht toString() und man braucht keinen "Float..." etc. davor).
Andererseits: Welche Vorteile sollte eine toString()-Funktion, die dieselbe Funktionalität wie die Streams ("runden und abschneiden" ... aber Du willst doch bestimmt auch mal Werte als "hex" darstellen, Fließkommazahlen mit ',' statt mit '.' trennen wollen, und ... und ... und) gegenüber der derzeitigen Lösung bieten?

Ich habe den Eindruck, dass viele Leute (sorry, aber: Gerade Anfänger/Umsteiger) denken, dass streams/operator<<(), std::string und std::vector sich heimlich im Keller treffen, um sich dort von der dem Benutzer geklauten Performance Spiegeleier zu braten.
Lasst es Euch sagen: Es ist nicht so!
Wenn diese Konstrukte den Rechner beschäftigen, dann mit "Komfort" in Sachen
- Funktionalität (die sonst auch selbst implementiert werden müsste)
- Entwicklungsaufwand (durch "gutes" Design).
Deswegen halte ich die meistens dieser Vergleiche für ziemlichen Unsinn...

Gruß,

Simon2.

[t.schubert]

Ist ja OK, das Problem ist halt immer, dass man das den Leuten klar machen muss, die halt nicht so mit der Informatik unterwegs sind - und dafür braucht man halt sehr viel Nerven und guten Willen, da diese Leute meistens die Entscheidungsträger sind.
Ich habe das jetzt sauber erklärt, habe den Kompromiss zwischen Schnelligkeit, Sicherheit und Komfort gefunden und bedanke mich noch einmal für Eure Hilfe.

[Simon2]

t.schubert schrieb:

Ist ja OK, das Problem ist halt immer, dass man das den Leuten klar machen muss, die halt nicht so mit der Informatik unterwegs sind - und dafür braucht man halt sehr viel Nerven und guten Willen, da diese Leute meistens die Entscheidungsträger sind....

Wenn es gut (oder zumindestens nicht total grottige) Entscheidungsträger sind, sollten sie sich in solche Implementierungsdetails sowieso nicht einmischen, sondern Dir als Fachmann vertrauen. :p

(aber ich weiß, dass solche Traumprinzen rar sind)

Gruß,

Simon2.