Forum: Compiler & IDEs sprintf float


von Dirk H. (Gast)


Lesenswert?

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

von Kai S. (zigzeg)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dirk H. schrieb:
> Was mache ich falsch

Du schreibst uns zu wenig über deine Umgebung …

von >_ pr0 (Gast)


Lesenswert?

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

von Vincent H. (vinci)


Lesenswert?

-u_printf_float

von Dirk H. (Gast)


Lesenswert?

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 ?!?

von Dirk H. (Gast)


Lesenswert?

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 !

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Dirk H. (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Was kommt eigentlich raus, wenn du ein e-Format benutzt (%e)?

von Rolf Magnus (Gast)


Lesenswert?

Kann man das Dezimaltrennzeichen ggf. einstellen (locale)? Vielleicht 
ist es nicht richtig vorbesetzt.

von Dirk H. (Gast)


Lesenswert?

Jörg W. schrieb:
> Was kommt eigentlich raus, wenn du ein e-Format benutzt (%e)?

Das wird richtig angezeigt, inkl. "." und "E".

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

In der Tat seltsam.

Mach doch einen Support-Fall bei Keil auf dafür.

von Dirk H. (Gast)


Lesenswert?

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

von Vincent H. (vinci)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von mostefan (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.