Gast
#5012089
Hallo, ich habe folgendes Problem : char Buffer[50]; double wert; wert = 10000.0; ... sprintf( Buffer, "%2.2f",wert/1000.0); Ich erhalte als Ergebnis "10ñ00". Was mache ich falsch
Dirk H. schrieb: > Ich erhalte als Ergebnis "10ñ00". Ich denke der Fehler steckt irgendwo zwischen dem sprintf und der nicht gezeigten Art und Weise wie daraus das Ergebnis wird. In den gezeigten Zeilen kann ich jedenfalls keinen Fehler entdecken. ZigZeg
Dirk H. schrieb: > Was mache ich falsch Du schreibst uns zu wenig über deine Umgebung …
Gast
#5012119
Hallo Dirk, wo wird dir dieses Ergebnis angezeigt? Auf einem LCD? In einer Konsole? Hab keine Schäu und hau raus mit den Informationen :) Liebe Grüße
-u_printf_float
Gast
#5012154
Hallo, ich verwende µVision 5.23 ( MDK Cortex M). Der String wird zeichenweise auf einem Grafik-Display ausgegeben. Statt einem "." oder auch gerne einem "," erhalte ich halt das Sonderzeichen "ñ" (Buffer[2] = "164") Mit allen anderen Variablen-Typen funktioniert sprint, nur mit float nicht ?!?
Gast
#5012323
Ich selber vermute etwas in Richtung Stack-Overflow. Nur warum ? Ich werde das Problem erst einmal umgehen (Aufspalten in Integer, ...), aber ganz ehrlich, ich wuerde schon gerne wissen, wo mein Fehler liegt! Danke schon mal fuer die schnellen Antworten !
Hast du denn den Sourcecode der Bibliothek? Dann könntest du ja mal versuchen, das nachzuvollziehen. Weiß nicht, wie das bei Keil ist, bei IAR bekommt man den wohl mitgeliefert, und bei den Opensource-Toolchains hat man ihn ja sowieso. Ist denn nur der Punkt betroffen, d. h. wenn sich die Zahl ändert, stimmen die Ziffernwerte trotzdem noch?
Gast
#5012363
Jörg W. schrieb: > Hast du denn den Sourcecode der Bibliothek? Dann könntest du ja > mal > versuchen, das nachzuvollziehen. Weiß nicht, wie das bei Keil ist, > bei IAR bekommt man den wohl mitgeliefert, und bei den > Opensource-Toolchains hat man ihn ja sowieso. > > Ist denn nur der Punkt betroffen, d. h. wenn sich die Zahl ändert, > stimmen die Ziffernwerte trotzdem noch? Die Ziffern werden richtig in Zeichen umgewandelt, egal welche Ziffer, egal wie viele Nachkommastellen , nur das Komma nicht.
Was kommt eigentlich raus, wenn du ein e-Format benutzt (%e)?
Gast
#5012385
Kann man das Dezimaltrennzeichen ggf. einstellen (locale)? Vielleicht ist es nicht richtig vorbesetzt.
Gast
#5012397
Jörg W. schrieb: > Was kommt eigentlich raus, wenn du ein e-Format benutzt (%e)? Das wird richtig angezeigt, inkl. "." und "E".
In der Tat seltsam. Mach doch einen Support-Fall bei Keil auf dafür.
Gast
#5012432
Jörg W. schrieb: > In der Tat seltsam. > > Mach doch einen Support-Fall bei Keil auf dafür. Das werde ich wohl machen, werde das Ergebnis hier veroeffentlichen. Ich bin das Problem erst einmal mit einer eigenen Funktion umgangen. Aufspalten in zwei Integer Variablen und dann sprintf(.%d,%d ..).
Ich tippe eher auf sowas wie "float support" in der Toolchain via flag deaktivierbar... In der newlib gibts sowas zum Beispiel via -u_printf_float.
Vincent H. schrieb: > Ich tippe eher auf sowas wie "float support" in der Toolchain via flag > deaktivierbar. Sieht in der Keil-Doku eher nicht danach aus. Was völlig gegen solch eine Theorie spricht ist, dass ja "%e" normal funktioniert.
Gast
#5012463
meines wissens gibt die zahl vor dem Punkt die Breite des gesamten Strings an. darf also nicht kleiner sein als die zweite Zahl. i.e. %5.2f gibt dir maximal 99.99
mostefan schrieb: > darf also nicht kleiner sein als die zweite Zahl. Dein Wissen ist nur im ersten Teil des Satzes richtig; die zitierte Schlussfolgerung hingegen ist falsch. Das war bei BASIC und FORTRAN (und wohl auch COBOL) so, bei C ist definiert, dass der String automatisch so breit wird wie nötig, auch wenn die angegebene Breite nicht ausreichen sollte. Die Ausgabe eines Dezimalpunktes als irgendein wahlloses Zeichen würde es allemal nicht rechtfertigen.