Das mit dem Creator kann ich nicht beantworten (im vi sehe ich immer beide Ausgaben
![Wink :wink:](./images/smilies/icon_e_wink.gif)
), aber:
kater hat geschrieben:Wiso behandeln? In ein Double passen 15 Stellen oder so und er hat grad mal 7. Was für Informationen sollte man den Computer denn noch geben.
Das ist nicht so einfach... "sehen" tust du die Zahl als Entwickler halt immer als String, welcher (nach bestimmten Regeln) erstellt werden muss. Diese Regeln müssen halt als Entwickler vorgegeben werden (dein '%f'), denn vielfach (eigentlich sogar meistens) möchte man den tatsächlichen Inhalt gar nicht sehen... (Wen interessierts, dass die 6. Nachkommastelle von "double x = 10000000000.0-0.3;" nicht korrekt ist?).
Die gleichen Regeln ergeben die gleichen Ausgaben:
Code: Alles auswählen
fprintf(stderr, "%f %.2f %.1f\n",d,d,d);
qDebug() << QString::number(d,'f') << QString::number(d,'f',2)
<< QString::number(d,'f',1) ;
Also: der Operator "<<" von qDebug für double ist etwas grosszügiger (das 'g'-Format, für verbesserte Lesbarkeit). So what?
Das Problem tritt nicht nur bei qDebug auf, sondern die Zahlen werden auch so weitergegeben (z.B. in die Datenbank).
Wer wandelt denn den double in den (SQL-)String? Also mit bindValue(..) des MySQL-Treibers klappts IMHO schon.. und bei einem direkten exec sollte halt der String auch wieder schön mit korrekten Formaten erstellt werden:
Code: Alles auswählen
qDebug() << "test5" << QString("INSERT INTO ...%1").arg(d,0,'f');
kater hat geschrieben:
Weil C das tut was man erwartet.
LOL <Kommentar wieder gelöscht... weil OT>
[EDIT]
bindValue sollte ziemlich sicher klappen, weil in einem Test QVariant(d).toString() den korrekten Wert ("---.67") ergeben hat...