VorwahlZeit=((2000*400)/400);// Soll=2000, Ist <100
7
VorwahlZeit=(1980*400/1023+20);// Soll=794.19, Ist <100
8
9
return(VorwahlZeit);
10
}
Warum kommt bei Formel 2,3 nicht die korrekte Zahl raus?
PS:
Prog.Sprache: C
uC: ATMEL ATtiny84
Zahlen innerhalb der Formel sind in Echt, Variable und
Präprozessor-Makro.
Fehler liegt eindeutig innerhalb des Formelaufbaus!
c-hater schrieb im Beitrag #5562477:
> Das ist dein Problem. C ist Scheisse. Du hast nur keine Ahnung, wie> Scheisse genau C ist. Dazu müsstest du C beherrschen. Tust du aber> offensichtlich nicht...>> Wäre das allerdings der Fall, könntest du trotz aller C-Idiotie in C> tatsächlich das erreichen, was du willst. Du müsstest halt nur lernen,> wie man das in C korrekt formuliert...
Blablabla...
1980*400 ist schon mal größer als die größte Zahl, die in uint16_t
passt.
Und Nachkommastellen kann INTEGER sowieso nicht.
STK500-Besitzer schrieb:> Blablabla...> 1980*400 ist schon mal größer als die größte Zahl, die in uint16_t> passt.
Noch ein Beweis das C Mist ist:
1
uint32_t VorwahlZeit;
VorwahlZeit ist als uint32 deklariert, mit VorwahlZeit und vollen
32 bit soll gerechnet werden, am Ende sollen die niederen 2 Bytes
als uint16 zurückgegeben werden.
Alles andere ist Mist, Fehlerhaft und dumm.
Aber das ist C sowieso...
Marc V. schrieb:> Aber das ist C sowieso...
Geh weg und nutz was anderes.
C hat gewisse Eigenschaften, wie jede andere Programmiersprache auch,
und wenn du nicht willens bist, diese zu erlernen, dann solltest du die
Nutzung auch unterlassen.
S. R. schrieb:> Geh weg und nutz was anderes.
Tue ich meistens auch.
> C hat gewisse Eigenschaften, wie jede andere Programmiersprache auch,
Eigenschaften unterscheiden sich aber von Blödheit und Idiotie.
> und wenn du nicht willens bist, diese zu erlernen, dann solltest du die> Nutzung auch unterlassen.
Was hat erlernen damit zu tun?
Ich habe es erlernt, muss ich deswegen mit jeder Dummheit einverstanden
sein ?
Wenn ich eine Variable als 32 bit deklariert habe, mit dieser aber nur
bis 16 bit rechnen kann, dann ist das für mich mehr als Blödheit - es
ist Idiotie.
Punkt.
c-hater schrieb im Beitrag #5562601:
> C ist einfach...
Ja.
> C ist portabel...
Ja.
Aber:
> Programmieren ist einfach.Nein.
> Portabel programmieren ist einfach.Nein.
Wie blöd muss eine Programmiersprache sein, damit sie bei den oben
gezeigten Beispielen einer 32-Bit Variablen keine sinnvolle Zahl
zuweist?
Da merkt man, das C eine Sprache ist, die durch Bastelei über inzwischen
mehr als 45 Jahre immer wieder an die Entwicklung der Computertechnik
angepasst wurde und manchen Anachronismus mit sich rum schleppt.
S. R. schrieb:> c-hater schrieb im Beitrag #5562601:>> Programmieren ist einfach.> Nein.>>> Portabel programmieren ist einfach.> Nein.
Du bist ein Zitatfälscher. Nichts von dem angeblich zitierten Text
stammt von mir.
Nunja, derzeit kann das noch jeder selber nachlesen, aber dank der
Zensur kann man sich ja leider nicht darauf verlassen, dass das auch so
bleiben wird. Also möchte ich hier noch einmal ausdrücklich darauf
hingewiesen haben...
Also - mir ist es egal was der Eine oder Andere von C hält!
Solch sinnfreie Diskussionen bitte anderweitig führen.
Tatsächlch benötige ich als "return" keine Dezimalstellen.
Deklaration uint32_t habe ich nur benutzt, da der Wert innerhalb der
Formel auf 800 000 kommen kann.
Das Ergebins der Formal kann nie über 2 000 kommen - daher uint16_t.
__Son´s B. schrieb:> Also - mir ist es egal was der Eine oder Andere von C hält!
Das sollte dir auch egal sein.
> Solch sinnfreie Diskussionen bitte anderweitig führen.
Sinnfrei war die Diskussion nicht. Du bist nur zur unwissend, um deinen
Fehler zu erkennen, OBWOHL er im Laufe selbiger, direkt und indirekt,
mehrfach erwähnt wurde...
Sprich: du bist nicht nur von weitestgehender C-Unkenntnis geplagt,
sondern obendrein vom völligen Unvermögen des verstehenden Lesens.
Gaaanz schlechte Voraussetzungen für einen Programmierer, denn es hält
ihn davon ab, hinzuzulernen. Was allerdings Grundvoraussetzung ist, um
jemals wirklich Programmierer zu werden, ganz egal in welcher Sprache.
Tatsache ist: wirkliche Programmierer können in jeder Sprache
programmieren. Weil sie schlicht in der Lage sind, die Konzepte jeder
Sprache zu verstehen und daraus die Einschränkungen der Sprache ableiten
können. Sprich: der Kern eines guten Programmierers ist: logisch denken
zu können und zu Abstraktionen fähig zu sein. Das ist zwingend nötig für
die Umsetzung des Problems, genauso zwingend aber für die kompetente
Nutzung des zur Umsetzung verwendeten Werkzeugs, also der Sprache und
der Toolchain.
c-hater schrieb:> Sprich: du bist nicht nur von weitestgehender C-Unkenntnis geplagt,
Das bist in erster Linie Du, sonst würdest Du nicht Deinen Hass überall
ungefragt auskippen.
Lass das doch einfach mal bleiben. Ist ja nicht so, daß man Dir das noch
nie nahegelegt hätte.
__Son´s B. schrieb:> Tatsächlch benötige ich als "return" keine Dezimalstellen.> Deklaration uint32_t habe ich nur benutzt, da der Wert innerhalb der> Formel auf 800 000 kommen kann.
Das interessiert C aber bei der Berechnung erstmal nicht. Für die
Berechnung gilt nur, was auf der rechten Seite steht. Wenn du Konstanten
vom Datentyp long verwenden würdest, würde die Rechnung mit 32 Bit
ausgeführt werden, aber so nicht.
Wolfgang schrieb:> __Son´s B. schrieb:>> Tatsächlch benötige ich als "return" keine Dezimalstellen.>> Deklaration uint32_t habe ich nur benutzt, da der Wert innerhalb der>> Formel auf 800 000 kommen kann.>> Das interessiert C aber bei der Berechnung erstmal nicht. Für die> Berechnung gilt nur, was auf der rechten Seite steht. Wenn du Konstanten> vom Datentyp long verwenden würdest, würde die Rechnung mit 32 Bit> ausgeführt werden, aber so nicht.
Ja, sicher.
ulong = 8bit * 8bit ergibt auch nur 8 bit oder wie ?
Marc V. schrieb:> Das interessiert C aber bei der Berechnung erstmal nicht. Für die>> Berechnung gilt nur, was auf der rechten Seite steht. Wenn du Konstanten>> vom Datentyp long verwenden würdest, würde die Rechnung mit 32 Bit>> ausgeführt werden, aber so nicht.>> Ja, sicher.> ulong = 8bit * 8bit ergibt auch nur 8 bit oder wie ?
Nun habe ich aus lauter Verzweiflung mit übertriebenen Datentypen rum
experimentiert, aber keinen Fortschritt erfahren...
1
doubleZeitPoty_Vorwahl(void)
2
{
3
doubleVorwahlZeit;
4
5
//VorwahlZeit = (2000*(400/400)); // klappt
6
//VorwahlZeit = ((2000*400)/400); //fehler
7
VorwahlZeit=(1980*2000/1023+20);//fehler
8
9
return(VorwahlZeit);
10
}
Tatsächlich brauche ich hier eine konkrete und praktische Lösungen ---
jemand der mich ans Händchen nimmt ;-(
Dein Problem ist nicht die größe deiner Variable, sondern der Datentyp
der Konstanten.
Versuch doch mal
(2000ul*400)/400
das sogt dafür, das der compiler mit usigned long rechnet statt mit int.
Bei deiner ersten Rechnung rechnet er ja erst mal die 400/400 aus. Das
ist natürlich 1 und 2000/1 bleibt halt 2000
bei den anderen rechnet er erst mal 2000*400/1980*2000. Dieses Ergebnis
sprengt den Wertebereich von int auf dem Atmel. Dadurch wird der nächste
Schritt auch nicht richtig ausgeführt.
Hausaufgaben in C:
Definiere eine vorzeichenlose ganzzahlige Konstante oder ein Makro mit
Wert Dreitausendeinhunderteinundvierzig, sie soll unbesehen und
uneingeschränkt tauglich sein um in 16bit, 32bit, 64bit Berechnungen und
Zuweisungen sorgenfrei verwendbar sein.
Zusatzaufgabe: Cutti aber auch für gemischt signed/unsigned.
Beispiele: siehe Eröffnungspost, sie soll den Platz der Zahl "2000"
einnehmen, ohne die im Eröffnungspost beklagten Nachteile zu
verursachen.
Keiner N. schrieb:> Dein Problem ist nicht die größe deiner Variable, sondern der Datentyp> der Konstanten.>> Versuch doch mal>> (2000ul*400)/400>> das sogt dafür, das der compiler mit usigned long rechnet statt mit int.
DANKE, das ist das Problem!
War mir nicht mehr auf dem Schirm, dass eine undeklarierte Zahl erst
einmal von "int" aus geht.
Gibt es eine Möglichkeit, alle Zahlen die innerhalb des Codes auftauchen
könnten (schon im Kopfbereich) als "unsigned long" oder "float" zu
deklarieren?
Macros wurden in der Formel erst einmal durch Ganzzahlen ersetzt um den
Fehler einzukreisen und das Prinzip zu verstehen.
Tatsächlich wurden Macros eingesetzt - Klappt gut.
Definition jedes einzelnen Wertes finde ich aber Umständlich und
Fehleranfällig.
Kennt ihr hierzu eine plausible Lösung ohne auf Macros zu verzichten?
__Son´s B. schrieb:> Kennt ihr hierzu eine plausible Lösung ohne auf Macros zu verzichten?
Sprache wechseln, etwas für normale Menschen benutzen.
Wenn ich alles erst selber ausrechnen und danach auf Richtigkeit prüfen
muss, ist mit der Sprache etwas nicht in Ordnung.
Keiner N. schrieb:> Versuch doch mal>> (2000ul*400)/400>> das sogt dafür, das der compiler mit usigned long rechnet statt mit int.
Ja, aber nur in C.
Ansonsten wird immer mit soviel bits gerechnet wie die deklarierte
Variable hat.
2000 ist 11 bit, 16bit reichen also vollkommen für die Deklaration aus.
Warum soll es mit ul deklariert werden ?
Weil C eine logische Sprache ist oder weil C ein Haufen von
zusammengewürfelten Fehldeklarationen ist ?
Marc V. schrieb:> Sprache wechseln, etwas für normale Menschen benutzen.
Dein Sprachgebashe kannst Du gerne woanders ausüben. Wenn Du nichts
tatsächlich hilfreiches beizutragen hast, sind Deine Kommentare genauso
überflüssig wie die von dem anderen selbsternannten Sprachkritiker hier.
__Son´s B. schrieb:> Gibt es eine Möglichkeit, alle Zahlen die innerhalb des Codes auftauchen> könnten (schon im Kopfbereich) als "unsigned long" oder "float" zu> deklarieren?
Zwischen "unsigned long" oder "float" liegen Welten.
Sowohl Dynamikbereich als auch Anzahl der Stellen (als auch Codegröße
auf µC ohne FPU) unterscheiden sich um Welten. Was willst du genau?
Wie beschrieben geht es mir um eine generelle "Grunddeklaration", statt
"int" wenn nicht deklariert wird.
Speicherplatz und Prozessorgeschwindigkeiten spielen für mich aktuell
keine Rolle. Daher mein Bsp "unsigned long", "float".
Du könntest die Makros durch Konstanten ersetzen. Die haben einen
Datentyp.
Also statt
1
#define POTY_ZEIT_MIN (20ul)
schreibst du:
1
constunsignedlongPOTY_ZEIT_MIN=20;
oder du verwendest gleich die Datentypen mit definierten Längen:
1
#include<stdint.h>
2
constuint32_tPOTY_ZEIT_MIN=20;
Denn anders als behauptet entwickelt sich C sehr wohl weiter, man muss
nicht immer mit den Einschränkungen von K&R C oder C89 arbeiten, sondern
kann durchaus C99 oder C11 verwenden...
MfG, Arno
__Son´s B. schrieb:> Wie beschrieben geht es mir um eine generelle "Grunddeklaration", statt> "int" wenn nicht deklariert wird.
Schlecht, denn dann ist das Verhalten eines Codeabschnitts nicht mehr
lokal vorhersagbar. Kurz: Ich lese den Code und habe keine Ahnung, was
eigentlich passiert.
__Son´s B. schrieb:> Speicherplatz und Prozessorgeschwindigkeiten spielen für mich aktuell> keine Rolle.
Dann nimm Java, Javascript oder ähnliche Sprachen. Dort ist das so.
__Son´s B. schrieb:> Wie beschrieben geht es mir um eine generelle "Grunddeklaration", statt> "int" wenn nicht deklariert wird.
Verwende VISUAL BASIC und den Variablentyp VARIANT
__Son´s B. schrieb:>> Dann nimm Java, Javascript oder ähnliche Sprachen. Dort ist das so.> Danke, aber zu spät - keine Zeit für Neuanfang!
Dann merk dir das für später.
Die Antwort auf deine Frage hatte ich übrigens schon sehr früh gegeben,
du hast sie nur ignoriert. :-(
Rufus Τ. F. schrieb:> c-hater schrieb:>> Sprich: du bist nicht nur von weitestgehender C-Unkenntnis geplagt,>> Das bist in erster Linie Du
Ist das so? Mir scheint hingegen, ich hätte das Problem korrekt
identifiziert. Oder kannst du irgendwelche FAKTEN anführen, die dieser
Einschätzung widersprechen?
> Lass das doch einfach mal bleiben. Ist ja nicht so, daß man Dir das noch> nie nahegelegt hätte.
Tja, die Sache ist halt die: die FAKTEN habe sich in den letzten knapp
50 Jahren einfach nicht geändert. Deswegen werde ich sie natürlich
weiterhin zur Argumentation verwenden. Ob dir das nun passt oder nicht.
Übrigens halte ich deine Verweigerungshaltung bei der Zurkenntnissnahme
objektiver Fakten (obendrein in deinem Fall: ganz offensichtlich wider
besseren eigenen Wissens) für überaus tendenziös. Das kann und darf man
nicht unwidersprochen lassen, wenn man sich der objektiven Wahrheit
verpflichtet fühlt.
Sprich: sobald du (und die anderen C-only-Jünger) sich zur korrekten
Darstellung der objektiven Wahrheit durchringen, bist du mich auch
sofort los. ;o)
Ist doch absolut easy oder nicht?
c-hater schrieb:> Sprich: sobald du (und die anderen C-only-Jünger) sich zur korrekten> Darstellung der objektiven Wahrheit durchringen, bist du mich auch> sofort los. ;o)
In wie viele Sprachen hast du denn schon reingeguckt?
Wieso ist C (im Embedded-Bereich) so verbreitet?
Welche Fakten hast du genannt?
Die sind mir wohl durch dein Rumgebölke entgangen.
Wenn du einen schlechten Tags hast/hattest: Lauf ne Runde um Block, aber
lass deinen Frust nicht an anderen aus.
main.c:9:23: warning: integer overflow in expression [-Woverflow]
3
VorwahlZeit = ((2000*400)/400); // Soll=2000, Ist <100
4
^
Warum wird auf 16 bit Überlauf gewarnt ?
Es soll überhaupt nicht gewarnt werden und es soll mit vollen
32 bit gerechnet werden weil VorwahlZeit als 32 bit deklariert ist.
Alles andere ist ein riesengroßer Fehler.
Morgen werden vielleicht uC mit 64 oder 128 bit üblich sein, wird
dann immer noch munter mit 16 bit und Überlauf gerechnet werden ?
Die linke Seite bestimmt immer welches Format das Resultat hat.
Ist es so schwer zu verstehen ?
Aber nein, hier wird stur C verteidigt, trotz offensichtlicher
Fehler.
Was noch schlimmer ist, jeder der etwas gegen C sagt, wird sofort von
der C Gemeinde (wovon die meisten wenig oder überhaupt keine Ahnung
von C haben) sofort angegriffen und angespuckt.
Warum ?
Weil die meisten im Grunde wissen, dass es ein Fehler ist, aber selber
nicht genug Ahnung davon haben, um es verteidigen zu können und da
ist mitschwimmen mit der Mehrheit die beste Möglichkeit, etwas zu
sagen, auch wenn diese "Experten" nichts zu sagen haben oder gar nicht
wissen, wovon sie reden.
Marc V. schrieb:> Alles andere ist ein riesengroßer Fehler.
Nein, alles andere ist ein Fehler in deiner Annahme über die
Funktionsweise. Jeder Ansatz hat Grenzen und Einschränkungen, und jede
Lösung besteht aus Kompromissen.
Marc V. schrieb:> Die linke Seite bestimmt immer welches Format das Resultat hat.
Die linke Seite bestimmt das Format des Ergebnisses, nicht aber das
Format möglicherweise auftretender Zwischenergebnisse. Du kannst das
Thema ja mal mit Fließkommazahlen durchspielen.
Marc V. schrieb:> Ist es so schwer zu verstehen ?
Nein, aber ich fürchte, mit dem Thema "Rundungsungenauigkeiten" bist du
ebenfalls überfordert.
Marc V. schrieb:> Aber nein, hier wird stur C verteidigt,> trotz offensichtlicher Fehler.
Das, was du als Fehler betrachtest (nämlich "int" als Maßstab), ist ein
Kompromiss aus einer Zeit, in der du vermutlich noch nichtmal gelebt
hast. Du darfst jetzt wie ein kleines Kind auf und nieder stampfen,
brüllen, schreien und heulen, aber die Entscheidung ist nunmal gefallen.
Du darfst dafür argumentieren, dass man das gefälligst jetzt schleunigst
ändern sollte. Dafür gibt es ebenfalls gute Gründe, Kompatiblität mit
existierendem Code gehört allerdings nicht dazu.
Schau dich in der Welt um, wieviel Scheiße aus Kompatiblitätsgründen
existiert. Vielleicht merkst du dann, dass es manchmal gute Gründe gibt,
mäßig gute Entscheidungen weiter zu tragen, statt sie mit Gewalt zu
ersetzen.
Beispiele wären gewisse Teile von POSIX, einige Teile von Windows, an
sich das gesamte Bankensystem (inklusive nächtlicher Batchprozesse),
oder die Reisesysteme (egal ob Flug- oder Schiffsreisen). Auch deine
Schuh- und Hosengrößen, oder die imperialen Gewinde der Schrauben in
deinen Gehäusen sind historisch gewachsene Kompatiblitätsschrotthaufen.
Und so geht es weiter, vom Kleinen bis zum Großen und wieder zurück.
S. R. schrieb:> Die linke Seite bestimmt das Format des Ergebnisses, nicht aber das> Format möglicherweise auftretender Zwischenergebnisse.
Und gerade das ist ein Fehler.
Ich kann 8 bit mit 8 bit multiplizieren, das Ergebnis kann nicht
grösser als 16 bit sein, aber wenn das Resultat einer 32 bit Variablen
zugewiesen werden soll, dann stelle ich auch 32 bit für
Zwischenergebnisse bereit und nicht stur 16 bit.
> Du darfst dafür argumentieren, dass man das gefälligst jetzt schleunigst> ändern sollte. Dafür gibt es ebenfalls gute Gründe, Kompatiblität mit> existierendem Code gehört allerdings nicht dazu.
Natürlich nicht, aber Kompatibilität mit zukünftigem Code schon.
Ich will nicht in 20 Jahren immer noch überlegen ob Zwischenergebnisse
in 16 bit, 32 bit, 64 bit oder 8 bit bereitstehen, warum auch ?
Ich will (wie es normal ist), dass Zwischenergebnisse mindestens
soviel bits haben wie das Resultat auch.
> Schau dich in der Welt um, wieviel Scheiße aus Kompatiblitätsgründen> existiert.
Ja, aber den meisten von uns ist britische oder amerikanische
Schuh- oder Hosengröße so was von egal weil es Umrechnungstabellen
dafür gibt.
Wenn aber in irgendeiner dieser Umrechnungstabellen die falsche
Größe drinstehen würde, wäre das eine ganz andere Sache...
Marc V. schrieb:>> Die linke Seite bestimmt das Format des Ergebnisses, nicht aber das>> Format möglicherweise auftretender Zwischenergebnisse.>> Und gerade das ist ein Fehler.
Warum? Weil dein Tellerrand zu hoch ist?
Du kannst 32 Bit durch 16 Bit dividieren und den Rest der Berechnungen
mit 16 Bit durchführen. Wozu 16 Bit verschwenden, wenn es teuer ist?
Du kannst ein paar Double-Berechnungen durchführen und das Ergebnis in
einem Minifloat speichern. Sollte die ganze Berechnung jetzt als
Minifloat stattfinden, weil das Ergebnis ein Minifloat ist?
Du fluchst und stampfst und schreist, aber deine Lösung hat die selben
Probleme an anderen Stellen. Du bist der Ingeneur, der einfach dickere
Schrauben nimmt, ohne zu bemerken, dass die Wand das Gewicht trotzdem
nicht trägt.
Marc V. schrieb:>> Dafür gibt es ebenfalls gute Gründe, Kompatiblität mit>> existierendem Code gehört allerdings nicht dazu.>> Natürlich nicht, aber Kompatibilität mit zukünftigem Code schon.
Die Existenz von zukünftigem Code ist nicht garantiert, die Existenz von
existierendem Code per Konstruktion schon.
Ich weiß, dass jetziger Code unter jetzigen Annahmen funktioniert.
Wenn ich an den Annahmen spiele, mache ich damit möglicherweise etwas
kaputt und die Kosten dieser Zerstörungswut sind höher als der
mittelfristige Nutzen.
Langfristig ist es egal, weil der Code irgendwann unter neuen Annahmen
neu geschrieben wird. Dabei ist auch ein Wechsel der Programmiersprache
kein Problem mehr.
Kurz:
- kurzfristig: Friss, was zu fressen da ist und halt Schnauze.
- mittelfristig: Friss. Wenn's dir nicht schmeckt, dann bau dir einen
Garten und friss trotzdem, sonst verhungerst du bis zur Ernte.
- langfristig: Ist doch egal, was es zu fressen gibt, bist doch Veganer.
Marc V. schrieb:> Die linke Seite bestimmt immer welches Format das Resultat hat.
Nicht in C. Da hat man sehr viel präziseren Einfluss darauf, wie
gerechnet werden soll.
1
inta;
2
intb;
3
floatc;
4
5
a=2;
6
b=3;
7
8
c=a*b;
Nach Deiner Sichtweise müsste hier eine float-Multiplikation
durchgeführt werden.
Genau das aber macht C nicht. Man kann es dazu zwingen, eine
float-Multiplikation durchzuführen (mit einem typecast eines der
Operatoren).
> Und gerade das ist ein Fehler.
Nein. Es ist einfach so, daß mit der nativen Wortgröße gerechnet wird,
solange nicht einer der Operatoren eine andere Größe festlegt.
Was auf der anderen Seite des Zuweisungsoperators steht, hat auf die
Berechnung keine Auswirkung.
Das ist eine grundlegende Spracheigenschaft, und darauf kann man sich
verlassen.
Diese Spracheigenschaft nicht zu verstehen, das ist ein Fehler.
> Morgen werden vielleicht uC mit 64 oder 128 bit üblich sein, wird> dann immer noch munter mit 16 bit und Überlauf gerechnet werden ?
Natürlich nicht, auf einem 64-Bit-µC wird die native Wortgröße dann 64
Bit betragen. Oder 32, wozu auch immer der Compilerbauer Lust und Laune
hat, und was sich anbietet.
Marc V. schrieb:> Morgen werden vielleicht uC mit 64 oder 128 bit üblich sein, wird> dann immer noch munter mit 16 bit und Überlauf gerechnet werden ?
Das selbe Programm heute für ein 32-Bit System z.B. STM32 oder einen
PC compiliert würde wie hier erwartet mit long berechnet werden.
Ich möchte nicht, dass auf einem 8-Bit System jede Berechnung mit long
durchgeführt wird. Ich möchte auch nicht, dass der Compiler solche Sache
ln nach Gutdünken "automatisch" heute so und morgen anders macht.
Das ist übrigens das "Systemverständnis", das ich im
Beitrag "Re: Als Informatiker in Embedded gehen?" vorhin erwähnt
habe: man muss seine Toolchain kennen, damit was Sinnvolles rauskommt.
> Nach Deiner Sichtweise müsste hier eine float-Multiplikation> durchgeführt werden.
Nein.
Multiplikation zwei Integerzahlen kann niemals einen float
erfordern. Casten zum Schluss reicht vollkommen.
Aber:
1
a = 2;
2
b = 3;
3
4
c = a / b;
Hier soll eine float-Division durchgeführt werden und das ist logisch
und wäre auch so zu erwarten.
Demgegenüber:
1
a = 20;
2
b = 3;
3
4
b = a / b;
Hier soll natürlich in integer gerechnet werden und dann kann der
Integer hier so breit sein, wie von der Sprache definiert, es stört
keinen normalen Menschen und es wird auch so erwartet.
In allen 3 Fällen aber stur mit 16 bit zu rechnen ist auf jeden Fall
falsch.
Und auch wenn morgen die übliche Registerbreite 32 oder 64bit wird
und dann mit soviel bits gerechnet wird, ist es immer noch falsch.
Lothar M. schrieb:> Ich möchte nicht, dass auf einem 8-Bit System jede Berechnung mit long> durchgeführt wird.
Jetzt ist es ist aber so, ob du es wahrhaben willst oder nicht.
Jede Berechnung wird mit 16 bit durchgeführt.
> Ich möchte auch nicht, dass der Compiler solche Sache> ln nach Gutdünken "automatisch" heute so und morgen anders macht.
Nicht nach Gutdünken, sondern nach gefordertem Format.
Zusammengefasst willst du also inkonsistente, schwer verständliche
Regeln haben, weil sie dir im Augenblick sinnvoll erscheinen.
Wie sieht das mit Zwischenergebnissen in Ausdrücken wie "a + (b + c * d)
/ e - f" aus? Wandelst du da ständig zwischen Float und Integer umher
oder soll alles mit der maximal möglichen Bitbreite (also __int128 oder
quadfloat) berechnet werden?
Wie sieht das mit Rundungsungenauigkeiten aus, die man bei "float" vs
"double" und insbesondere bei Minifloats bekommt? Hast du dir da mal
Gedanken gemacht?
C besteht aus einfachen Regeln. Deswegen kann man einen Compiler in ein
paar zig KB bauen. Offensichtlich magst du lieber komplizierte Regeln,
die vom dynamisch vom Anwendungsfall abhängen, je nachdem, was du gerade
möchtest.
Gehe zu Scriptsprachen. Am besten denen, wo '=', '==' und '==='
unterschiedliches Verhalten zeigen, aber keines davon logisch ist.
Vielleicht gefällt's dir da besser.
Marc V. schrieb:> In allen 3 Fällen aber stur mit 16 bit zu rechnen> ist auf jeden Fall falsch.
Es wird ja nicht immer stur mit 16 Bit gerechnet.
Das ist eine Fehlinformation.
S. R. schrieb:> Wie sieht das mit Zwischenergebnissen in Ausdrücken wie "a + (b + c * d)> / e - f" aus?
Und wie sieht es jetzt bei dir aus ?
> Wandelst du da ständig zwischen Float und Integer umher> oder soll alles mit der maximal möglichen Bitbreite (also __int128 oder> quadfloat) berechnet werden?
Wie schon mehrmals gesagt, es soll mit gefordertem Format gerechnet
werden und ob float oder integer das muss nur bei der Division
wirklich beachtet werden.
Aber was hat das alles überhapt damit zu tun, daß 32 bit gefordertsind, aber nur mit 16 bit gerechnet wird ?
Das ist es was ich oben schon sagte - Wehe, jemand wagt es, überhaupt
daran zu denken, C hätte irgendwelche Fehler...
Marc V. schrieb:> Aber was hat das alles überhapt damit zu tun, daß 32 bit gefordert> sind, aber nur mit 16 bit gerechnet wird ?
C rechnet nicht grundsätzlich mit 16 Bit. Du bist falsch informiert.
Marc V. schrieb:> Das ist es was ich oben schon sagte - Wehe, jemand wagt es, überhaupt> daran zu denken, C hätte irgendwelche Fehler...
Alles Geisterfahrer außer deiner Wenigkeit. Is kla.
Hättest du mal gelesen, was ich oben schrieb. Aber du willst nur einen
c-hater machen und geifern. Nungut, reicht mit.
S. R. schrieb:> Marc V. schrieb:>> Aber was hat das alles überhapt damit zu tun, daß 32 bit gefordert>> sind, aber nur mit 16 bit gerechnet wird ?>> C rechnet nicht grundsätzlich mit 16 Bit. Du bist falsch informiert.>> Marc V. schrieb:>> Das ist es was ich oben schon sagte - Wehe, jemand wagt es, überhaupt>> daran zu denken, C hätte irgendwelche Fehler...>> Alles Geisterfahrer außer deiner Wenigkeit. Is kla.>> Hättest du mal gelesen, was ich oben schrieb. Aber du willst nur einen> c-hater machen und geifern. Nungut, reicht mit.
Ja sicher.
So etwas nennt man straw man argumentExperte schrieb:>
1
> main.c: In function ‘ZeitPoty_Vorwahl’:
2
> main.c:9:23: warning: integer overflow in expression [-Woverflow]
3
> VorwahlZeit = ((2000*400)/400); // Soll=2000, Ist <100
4
> ^
5
> main.c:10:22: warning: integer overflow in expression [-Woverflow]
6
> VorwahlZeit = (1980*400/1023+20); // Soll=794.19, Ist <100
7
>
__Son´s B. schrieb:> Warum kommt bei Formel 2,3 nicht die korrekte Zahl raus?
Weil mit 16 bit gerechnet wird.
Vielleicht erklärt das jemand dem Geisterfahrer S.R.
P.S.
Selbstverständlich benutze ich auch C und denke nicht, dass es die
schlechteste Sprache ist.
Aber Fehler sind Fehler, egal in welcher Sprache.
TP4 hatte einen ähnlichen aber Borland hat es wenigstens zugegeben
und es korrigiert.
Marc V. schrieb:> Vielleicht erklärt das jemand dem Geisterfahrer S.R.
Falls es dir entgangen sein sollte... ich habe die Lösung des Rätsels
schon gaaanz weit oben gepostet.
Und ich habe dir versucht zu erklären, dass dein "das ist ein Fehler;
das ist falsch; das ist böse" nicht stimmt. Dass da ein Sinn hinter
steht. Dass dein Lösungsvorschlag auch nicht besser ist, sondern nur
anders.
Interessiert dich nicht.
Du geilst dich an 16 Bit auf.
Wie immer halt. Alles Geisterfahrer außer du.
S. R. schrieb:> Marc V. schrieb:>> Vielleicht erklärt das jemand dem Geisterfahrer S.R.>> Falls es dir entgangen sein sollte... ich habe die Lösung des Rätsels> schon gaaanz weit oben gepostet.
Nein, hast du nicht, du hast ihm nur einen Weg gezeigt, wie dieser
Fehler umgangen werden kann.
Die Lösung des Rätsels ist immer noch:
Es wird mit 16 bit anstatt mit geforderten 32 bit gerechnet.
> Du geilst dich an 16 Bit auf.
Nein, aber es war diesmal tatsächlich der Fehler welchen der TO
gesucht hat.
> Wie immer halt. Alles Geisterfahrer außer du.
Wenn du meinst.
OK.
Marc V. schrieb:> Es wird mit 16 bit anstatt mit geforderten 32 bit gerechnet.
Ein "=" in C ist kein "Forderungszeichen", sondern eine Zuweisung. Und
diese Zuweisung wird nach der Berechnung gemacht. Wenn du eine
Berechnung mit 32 Bit Breite forderst, dann muss mindestens 1 Variable
diese Breite haben. Das ist dann eine Forderung.
So ist es halt in C. Bei anderen Sprachen mag das anders sein...
Lothar M. schrieb:> Ein "=" in C ist kein "Forderungszeichen", sondern eine Zuweisung.
Das ist klar.
> Und diese Zuweisung wird nach der Berechnung gemacht.
Das ist auch klar und üblich.
> Wenn du eine> Berechnung mit 32 Bit Breite forderst, dann muss mindestens 1 Variable> diese Breite haben.
Das ist weder klar noch üblich.
16bit * 16bit ergibt max. 32bit, selbst in C ist das so.
32bit * 16bit kann aber mehr als 32bit ergeben, selbst in C ist das
so.
Ich will und kann C-Regeln nicht ändern, aber ich kann so etwas als
unlogisch und fehlerhaft empfinden.
Marc V. schrieb:> Ich will und kann C-Regeln nicht ändern, aber ich kann so etwas als> unlogisch und fehlerhaft empfinden.
Wenn du die C-Regeln nicht ändern willst, warum schimpfst du dann über
alle, die die C-Regeln auch nicht ändern wollen? Irgendwie ist das
unlogisch.
Marc V. schrieb:>> Wenn du eine Berechnung mit 32 Bit Breite forderst,>> dann muss mindestens 1 Variable diese Breite haben.> Das ist weder klar noch üblich.
Eine artihmetische Operation findet mit der Bitbreite des größten
Operanden statt, jedoch mindestens mit der Größe eines "int".
Was ist daran für dich zu schwer zu verstehen?
Und das Grundproblem hast du noch immer nicht gelöst.
S. R. schrieb:> Wenn du die C-Regeln nicht ändern willst, warum schimpfst du dann über> alle, die die C-Regeln auch nicht ändern wollen? Irgendwie ist das> unlogisch.
Wo habe ich das gemacht?
> Eine artihmetische Operation findet mit der Bitbreite des größten> Operanden statt, jedoch mindestens mit der Größe eines "int".
LOL.
1
uint8_t secs = 60;
2
uint8_t mins = 60;
3
uint8_t hours = 24;
4
5
uint32_t SecProTag;
6
7
SecProTag = secs * mins * hours;
Was ist daran für dich zu schwer zu verstehen?
> Und das Grundproblem hast du noch immer nicht gelöst.
Welches wäre ?
Marc V. schrieb:> LOL.
Wie niveauvoll.
Marc V. schrieb:> *Was ist daran für dich zu schwer zu verstehen?*
Erstens: Schrei mal nicht so rum, wir sind hier nicht im Kindergarten
und ich brauch keinen Sehsturz.
Zweitens: Alle Operanden sind uint8_t. Da uint8_t kleiner als "int" ist,
wird die Rechnung also mit "int" durchgeführt. So ist das nunmal
definiert.
Drittens: Erst wird gerechnet, dann zugewiesen. Das ist auch logisch,
denn nicht jedes Rechenergebnis wird irgendwo zugewiesen, wo man einen
Datentyp raus inferieren könnte.
Marc V. schrieb:>> Und das Grundproblem hast du noch immer nicht gelöst.> Welches wäre ?
Welcher Datentyp deiner Meinung nach für Zwischenergebnisse angemessen
wäre, die nicht einer Variable mit bekanntem Datentyp zugewiesen werden.
Und jetzt?
Muss die Berechnung jetzt 48 Bit breit stattfinden? Oder doch nur mit 32
Bits?
Was soll der Compiler jetzt tun? Immerhin sind das Variablen, die Werte
bis 255 annehmen können.
Lothar M. schrieb:> Muss die Berechnung jetzt 48 Bit breit stattfinden? Oder doch nur mit 32> Bits?
Wie kommst du auf 48 Bit.
Guck dir die Größe von deinem Ergebnis an und vergleiche das mit dem
Wertebereich einer 32-Bit bzw. 48-Bit Zahl.
Deine Einzelwerte benötigen etwas weniger als 4, 5 oder 6 Bit.
Marc V. schrieb:> Nein.> Multiplikation zwei Integerzahlen kann niemals einen float> erfordern. Casten zum Schluss reicht vollkommen.
nach deiner Argumentation schon, siehe:
float ergebnis;
ergebnis = 32000*30000;
S. R. schrieb:> Erstens: Schrei mal nicht so rum, wir sind hier nicht im Kindergarten> und ich brauch keinen Sehsturz.
Ich schreie nicht rum, das steht schon mal fest.
> Zweitens: Alle Operanden sind uint8_t. Da uint8_t kleiner als "int" ist,> wird die Rechnung also mit "int" durchgeführt. So ist das nunmal> definiert.>> Drittens: Erst wird gerechnet, dann zugewiesen. Das ist auch logisch,> denn nicht jedes Rechenergebnis wird irgendwo zugewiesen, wo man einen> Datentyp raus inferieren könnte.
Ich gebe es auf.
Du hast wirklich solch enorme Schwierigkeiten etwas so einfaches und
offensichtliches zu verstehen, daß ich mich wirklich frage ob du aus
dem Kindergarten schreibst...
Lothar M. schrieb:> Und jetzt?
Wieder in die Schule gehen, lernen zu multiplizieren und wieviele
bits nötig sind, um eine Zahl anzuzeigen.
> Was soll der Compiler jetzt tun? Immerhin sind das Variablen, die Werte> bis 255 annehmen können.
Abgeschniten auf 32 bits mit Überlauf, natürlich.
Wer so dumm ist und nicht weisst wieviele bits nötig sind um das
Resultat anzuzeigen, verdient es nicht besser.
Walter schrieb:> Marc V. schrieb:>> Nein.>> Multiplikation zwei Integerzahlen kann niemals einen float>> erfordern. Casten zum Schluss reicht vollkommen.>> nach deiner Argumentation schon, siehe:>> float ergebnis;>> ergebnis = 32000*30000;
Noch einer der mit Gewalt etwas verdrehen will.
Nach welcher Argumentation ?
Für das Resultat reicht uint32_t vollkommen.
Lothar M. schrieb:> Und jetzt?Marc V. schrieb:> Abgeschniten auf 32 bits mit Überlauf, natürlich.> Wer so dumm ist und nicht weisst wieviele bits nötig sind um das> Resultat anzuzeigen, verdient es nicht besser.
Damit es keine Missverständnisse gibt:
Du warst nicht gemeint, diese Aufgabe war nicht gemeint, es war
eine hypothetische Antwort auf eine hypothetische Aufgabe, wo das
Ergebnis tatsächlich 48 bit oder mehr betragen hätte...
Marc V. schrieb:> wo das Ergebnis tatsächlich 48 bit oder mehr betragen hätte
Woher soll denn der Compiler vor der Multiplikation von sechs 8
Bit-Zahlen wissen, dass deren Ergebnis in eine 32 Bit-Variable passt, um
dann die Multiplikationen in 32 Bit ausführen zu können?
Ich fürchte, Kausalität ist auch nix für dich.
S. R. schrieb:> Woher soll denn der Compiler vor der Multiplikation von sechs 8> Bit-Zahlen wissen, dass deren Ergebnis in eine 32 Bit-Variable passt, um> dann die Multiplikationen in 32 Bit ausführen zu können?
Soll er auch nicht und es hat ihn nicht zu interessieren ob das
Ergebnis in eine 32bit Variable passt oder nicht.
Nur darf es nicht passieren, daß das Ergebnis oder die Zwischenwerte
irgendwann und irgendwo auf 16bit abgeschnitten werden.
Sondern natürlich als volle 32bit zurückgegeben werden.
Eine dezente Warnung auf Überlauf würde aber in diesem speziellem
Fall auch nicht schaden, mehr aber auch nicht...
> Ich fürchte, Kausalität ist auch nix für dich.
Und ich fürchte, Logik ist auch nix für dich.
Marc V. schrieb:> S. R. schrieb:>> Woher soll denn der Compiler vor der Multiplikation von sechs 8>> Bit-Zahlen wissen, dass deren Ergebnis in eine 32 Bit-Variable passt, um>> dann die Multiplikationen in 32 Bit ausführen zu können?>> Soll er auch nicht und es hat ihn nicht zu interessieren ob das> Ergebnis in eine 32bit Variable passt oder nicht.> Nur darf es nicht passieren, daß das Ergebnis oder die Zwischenwerte> irgendwann und irgendwo auf 16bit abgeschnitten werden.
Wir haben alle verstanden, dass du das forderst. Du bist aber für die
Sprache C nicht relevant, und der C-Standard fordert das nicht. Das hast
du bisher nicht verstehen wollen.
> Sondern natürlich als volle 32bit zurückgegeben werden.
Wäre ja auch noch schöner, wenn der Compiler 16 der 32 Bit austrinken
und leer zurückgeben würde ;)
MfG, Arno
Arno schrieb:> Wäre ja auch noch schöner, wenn der Compiler 16 der 32 Bit austrinken> und leer zurückgeben würde ;)S. R. schrieb:> Warum eigentlich gerade 32, und nicht 48 oder 64?
Nur für schwachsinnige Idioten:
Weil VorwahlZeit als uint32_t deklariert wurde.
Für Moderatoren:
Sollte dies gelöscht werden, heisst es, dass die beiden Idioten
sind, falls es nicht gelöscht wird, sind es 2 hypothetische
Idioten.
Marc V. schrieb:> Weil VorwahlZeit als uint32_t deklariert wurde.
Du schreist immernoch (Fettschrift). Plenken tust du sowieso.
Was ist mit Rechenoperationen, die nicht direkt in einer
Variablenzuweisung münden? Und warum sollte ich bei einer Zuweisung an
einen uint32_t alle Rechenoperationen mit exakt 32 Bit durchführen
müssen?
Ganz einfach: Weil du nicht für 5 Pfennig nachdenkst, was dir andere
schreiben.
S. R. schrieb:> Du schreist immernoch (Fettschrift). Plenken tust du sowieso.
Nein, dafür gibt es Ausrufungszeichen und Grossbuchstaben.
Mit Fettschrift und Unterstreichen betont man etwas, es soll aber
nicht alles so geschrieben werden. Ein Satz ist aber durchaus erlaubt
und üblich.
Plenken (aber nur mit Ausrufungs- und Fragezeichen) werde ich auch
weiter tun, weil es viel übersichtlicher ist und weil ich es so mag.
> Was ist mit Rechenoperationen, die nicht direkt in einer> Variablenzuweisung münden?
Uninteressant, es muss nur sichergestellt werden, dass mindestens
(in diesem Fall) 32 bit als Ergebnis der Operation bereitgestellt
werden.
> Und warum sollte ich bei einer Zuweisung an> einen uint32_t alle Rechenoperationen mit exakt 32 Bit durchführen> müssen?
Erstens, Computer macht das, nicht du und zweitens, niemand hat das
verlangt, solange das Ergebnis stimmt.
S. R. schrieb:> Ganz einfach: Weil du nicht für 5 Pfennig nachdenkst, was dir andere> schreiben.
Nein, weil Ihr alle so überzeugt seid das C fehlerfrei ist, dass
es Euch gar nicht interessiert, worum es hier eigentlich geht.
Nicht darum, ob C gut oder schlecht ist, sondern darum, ob dies
ein Fehler ist oder nicht.
Und es ist ein Fehler, aber dich interessiert es genauso wenig, was
andere schreiben.
Nimm dieses Beispiel:
Beitrag "Re: Formel-/Berechnungsprobleme"
Alle anderen Sprachen (zumindest die, die ich kenne und benutze)
rechnen das richtig aus, nur C nicht.
Und dann kommst du und noch ein paar Sturköpfe mit der Behauptung:
"ja das ist vollkommen in Ordnung so, das muss so sein, wenn du es
richtig haben willst musst du folgende Verrenkungen machen aber das
ist auch ganz in Ordnung so".
Ich will aber keine Verrenkungen machen, ich will normale Programme
schreiben und mich aufs Wesentliche konzentrieren, nicht auf die
stundenlange Fehlersuche im Programm.
Wenn ich in C programmieren will, muss ich mich damit abfinden,
aber deswegen muss ich noch lange nicht behaupten, das es ganz
normal und kein Fehler ist.
Hallo,
Marc V. schrieb:> Nein, weil Ihr alle so überzeugt seid das C fehlerfrei ist...
Das "alle so überzeugt sind das C fehlerfrei ist" unterstellst du den
Anderen und ist hier nie geäußert worden.
> Und es ist ein Fehler, aber dich interessiert es genauso wenig, was> andere schreiben.
Das ist deine Meinung, aber wie mehrfach ausgeführt wurde ist es einfach
eine Eigenschaft von C. Man kann jetzt darüber streiten ob diese
Eigenschaft gut oder schlecht ist (ich persönlich halte sie für ziemlich
problematisch), aber das ändert nichts daran das sie so ist wie sie ist.
> Und dann kommst du und noch ein paar Sturköpfe mit der Behauptung:> "ja das ist vollkommen in Ordnung so, das muss so sein, wenn du es> richtig haben willst musst du folgende Verrenkungen machen aber das> ist auch ganz in Ordnung so".
Wieder eine Interpretation von dir was andere für vollkommen in Ordnung
halten.
> Wenn ich in C programmieren will, muss ich mich damit abfinden,> aber deswegen muss ich noch lange nicht behaupten, das es ganz> normal und kein Fehler ist.
Richtig, und das ist praktisch auch genau das was hier alle "Anderen"
sagen.
rhf
P.S.:
Das ist jetzt schon die zweite Diskussion in dieser Woche in der
"C-Gegner" völlig ausrasten und mit verbalen Entgleisungen auf ihre
Kontrahenten losgehen. Kommt mal runter.
Ihr solltet mal ein wenig in euch gehen und klar machen das es hier
"nur" um eine pragmatische Programmiersprache geht, die zu einer Zeit
und von Leuten entwickelt wurde, die damit einfach nur ihre damaligen
Probleme lösen wollten. Und diese Leute waren keine theoretischen
Informatiker oder Linguisten. Wenn diese Personen geahnt hätten, das C
jemals solch eine Bedeutung erlangen würde, hätten sie sich beim Entwurf
der Sprache sicher mehr Gedanken gemacht.
S. R. schrieb:> Woher soll denn der Compiler vor der Multiplikation von sechs 8> Bit-Zahlen wissen, dass deren Ergebnis in eine 32 Bit-Variable passt, um> dann die Multiplikationen in 32 Bit ausführen zu können?
Er weiss es überhaupt nicht. DU musst es beim Schreiben des Programms
wissen und ihm sagen, mit welchem Typ er arbeiten soll. Beim Fehlen
weiterer Anweisungen nimmt er int.
Roland F. schrieb:> Das ist jetzt schon die zweite Diskussion in dieser Woche in der> "C-Gegner" völlig ausrasten und mit verbalen Entgleisungen auf ihre> Kontrahenten losgehen. Kommt mal runter.
Nun, ich finde nicht, dass ich völlig ausgerastet bin. Sollte dies
trotzdem der Fall sein und ich jemanden beleidigt habe, entschuldige
ich mich hiermit.
Marc V. schrieb:> Nun, ich finde nicht, dass ich völlig ausgerastet bin.
Das finde ich allerdings doch!
Marc V. schrieb:> Sollte dies> trotzdem der Fall sein und ich jemanden beleidigt habe,
Auch ich könnte ich dir sagen: Ja!
Wie du die Leute angehst, hat was beleidigendes/herabwürdigendes.
Marc V. schrieb:> entschuldige ich mich hiermit.
Du kannst um Verzeihung bitten.
Das ist eine Gnade, welche dir das jeweilige Opfer gewähren kann.
Du hast kein Recht das einzufordern.
Niemals darf sich ein Verursacher von Leid und Streit, selbst von seiner
Schuld befreien. Das wäre tief amoralisch/unethisch.
Arduino Fanboy D. schrieb:> Marc V. schrieb:>> entschuldige ich mich hiermit.> Du kannst um Verzeihung bitten.> Das ist eine Gnade, welche dir das jeweilige Opfer gewähren kann.> Du hast kein Recht das einzufordern.>> Niemals darf sich ein Verursacher von Leid und Streit, selbst von seiner> Schuld befreien. Das wäre tief amoralisch/unethisch.
Aber sonst geht es dir ganz gut, oder ?
Ich meine, keine Schmerzen, keine Stimmen aus dem Hintergrund die dir
etwas unmoralisches befehlen oder so etwas ?
Naja, Marcs Tonfall mag etwas grenzwertig gewesen sein, auch wirkten
seine fortwährenden Hervorhebungen sehr anstrengend besserwisserisch
und laut, aber daß er direkt Leute beleidigt hat, kann ich nicht
bestätigen. Das hat hier in diesem Thread nur der andere Clown
hinbekommen, der ohne Beleidigungen anscheinend seine Ahnungslosigkeit
nicht verbreiten kann.
Tip für Marc: Versuch nächstes mal diese Art von Hervorhebung zu
verwenden, die wirkt weniger aufdringlich.
Rufus Τ. F. schrieb:> Tip für Marc: Versuch nächstes mal diese Art von Hervorhebung zu> verwenden, die wirkt weniger aufdringlich.
OK, angekommen.
Abr um auf das Problem zurückzukommen:
Bei der Typkonvertierung wird nur von Operanden gesprochen, was
zum Trugschluss führen kann, dass die Operation/en danach richtig
ausgeführt werden.
Es wird u.a. aufgeführt wie die Operanden umzuwandeln sind, damit
es zu einem allgemeinen typ kommt.
Und dann:
Wenn keine der aufgeführten Bedingungen zutrifft (ulong, uint, float,
double, etc.) werden alle Operanden mindestens auf den Typ integer
umgewandelt.
Und der Zweck ist ?
ZITAT:
1
Der Zweck besteht darin, einen allgemeinen Typ zu erhalten, der gleichzeitig der Ergebnistyp ist.
In diesem Fall wurde der Ergebnistyp aber explizitals 32bit deklariert.
Was aber noch schlimmer ist:
Wie wir alle wissen, kann eine 16bit*16bit Multiplikation zu einem
32bit Ergebnis führen (muss natürlich nicht).
Deswegen ist:
uint32_t = uint16_t * uint16_t
richtig und so hat es der TO gemacht.
Aber:
uint16_t = uint16_t * uint16_t
falsch und so hat es der Compiler gemacht.
Was muss man dem Compiler noch mitteilen, damit es richtig gemacht
wird ?
Marc V. schrieb:> Was muss man dem Compiler noch mitteilen, damit es richtig gemacht> wird ?
Mann muss ihm sagen, dass man mit seinem Wissen als Programmierer nicht
nur die Zuweisung, sondern auch die Berechnung in 32 Bit haben will. Und
dann schreibt man ul hinter eine Konstante oder man castet einen der
Operanden auf 32 Bit.
Ich meine, dass das schon wiederholt im Thread angesprochen wurde. So
ist C einfach, wenn einem das nicht gefällt, muss man eine andere
Sprache verwenden.
Kleiner Abschweif: in VHDL muss die Vektorbreite vom Programmierer aufs
Bit genau bekannt gemacht und ausgeschrieben werden, sonst gibt es eine
Fehlermeldung.
Thread beobachten
Seitenaufteilung abschalten