|
Anzeige
|
rechnfehler mit standartrechnung uint32_t
Gast
#4483521
programm rechnet falsch, bin ich zu blöd oder was? :-)
#include "suart.h"
#include "string.h"
#include "sms.h"
#include <stdint.h>
volatile uint32_t min=0;
char zahl_buffer[7];
uint32_t getMinuten()
{
stunde=1;
monat=1;
minute=1;
jahr=0;
min=1+(1*60)+(1*30*60*24)+(1*365*24*60);
return min;
}
ergebnis: 4294946333 anstatt: 568861
Christian schrieb: > min=1+(1*60)+(1*30*60*24)+(1*365*24*60); Lass mich raten: Die Berechnung wird in int durchgeführt und der ist auf deiner Plattform 16 Bit breit. Es kommt zum Überlauf und anschliessend wird die negative Zahl in einen uint32_t gecastet, was in einer grossen Zahl resultiert. Der Typ der linken Seite einer Zuweisung hat keinerlei Einfluss auf die Rechnung auf der rechten Seite.
Gast
#4483536
hallo Be Stucki, ich habe extra alle variablen entfernt. die zielvariable kommt direkt nach uint32t: min und trotzdem habe ich das falsche ergebnis. komisch.
Gast
#4483541
an der stand-art liegts sicher nicht. was für eine platform ist das? anscheinend ist dort int nur 16bit gross, dann rechnet er also in 16 bit int, und interpretiert das am schluss als uint32_t, da kommt dann genau das raus. häng an die zahlen "ul" an, dann gehts ohne überlauf.
Gast
#4483543
> programm rechnet falsch Das Programm rechnet überhaupt nicht. Es ist unvollständig. > bin ich zu blöd oder was? :-) Dem ersten Teil kann ich nur zustimmen :)
Gast
#4483545
ich programmiere einen atmega16. Christian schrieb: > hallo Be Stucki, ich habe extra alle variablen entfernt. die > zielvariable kommt direkt nach uint32t: min und trotzdem habe ich das > falsche ergebnis.
Genau hier liegt dein Problem. Eine Zahl ist erstmal ein int. Wird damit gerechnet, ist es immernoch ein int. Ist das Ergebnis zu gross für einen int, gibts ein Überlauf, das Ergebnis ist immernoch ein int. Du als Programmierer bist dafür verantwortlich, dass das Ergebis und auch alle Zwischenergebnisse einer Berechnung mit dem jeweiligen Datentyp repräsentierbar sind. Schau dir dazu die integer promotions an. Christian schrieb: > ich programmiere einen atmega16. Dann ist dein int 16 Bit breit und ich habe richtig geraten.
Gast
#4483562
danke Bernd für die bestätigung, danke rmu für den tipp, das ergebnis stimmt jetzt. also auf atmega16 keine 32bit zahlen? Christian schrieb: > also auf atmega16 keine 32bit zahlen? Doch. Aber nicht automatisch.
Gast
#4483568
danke Be Stucki! :-) nun komme ich weiter super!!!
Gast
#4483570
Christian schrieb: > programm rechnet falsch, bin ich zu blöd oder was? :-) Du bist nicht mal in der Lage, einen fehlerfreien Thread-Titel zu schreiben. Vier Fehler in vier Worten ist eine stolze Leistung.
Gast
#4483574
Christian, doch Du musst nur 1ul oder 1uul schreiben. Und nun rate mal wo das steht ? In einem C Buch - die Standard. Man könnte auch zur besseren Übersicht jede erste Zahl Casten:
Gast
#4483577
hallo Wolfgang meine oma hat zu mir gesagt: du kanns bloed sein so viel du willst, du must dir nur zu helfen wissen. lg
Gast
#4483578
Christian, was soll ich von deinen Fähigkeiten halten, wenn man das neurale Element der Multiplikation - die 1 - in eine Multiplikation auch schreibt ? Ok, den Präprozessor wird das nicht interessieren, aber dort stehen nur Konstanten, die kann man auch selbst als Ausdruck hinschreiben. Karl M. schrieb: > was soll ich von deinen Fähigkeiten halten, wenn man das neurale Element > der Multiplikation - die 1 - in eine Multiplikation auch schreibt ? Da es sich offensichtlich um einen verkürzten Beispielcode zur Illustration des Problems handelt ist diese Kritik hier fehl am Platz. > Ok, den Präprozessor wird das nicht interessieren Solltest du zu jenen gehören, die der Ansicht sind, dass der Präprozessor irgend etwas mit hier relevanten Teil des Codes zu tun hat, dann solltest du lieber selber mal das C Handbuch studieren und über die Rolle des Präprozessors nachdenken. Antwort schreiben |
Anzeige
|
