Formatierung in C++

pumuckl schrieb:

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

Ich finde dass du diese Dinge überbewertest.

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

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

Dravere

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.

Kommt im neuen Standard. Es wird ein to_string und ein to_wstring geben. Desweiteren stoi , stol , stoul , stoll , stoull , stof , stod , stold und was sonst noch alles ...
Der erste Buchstabe bedeutet String, dann ist das Wort to und dann die ersten Buchstaben des Typs. Also zum Beispiel stoull -> string to unsigned long long.

Zu den Streams:
Weiss eigentlich einer, was der Standard vorschreibt wegem dem Puffer? Wenn ich meinen Streams im VS2005 einen Puffer gäbe, dann habe ich die gleiche Geschwindigkeit wie beim printf . Die Implementation scheint mir daher nur insofern schlecht zu sein, dass nicht per Default ein Puffer verwendet wird.

Grüssli

berniebutt

Die Streamklassen von C++ machen alles gewünschte, einschliesslich geeigneter Manipulatoren für die Formatierung in <iomanip.h>, wie setw und setprecision. Für Umwandlungen von int nach hex sind itoa und ltoa geeignet. Die alten C-Funktionen für I/O braucht man dann nicht mehr.