Schade eigentlich, für mich klang das sehr plausibel.
Dann sollte ich den Text mal lieber wieder löschen, sonst glaubt das noch jemand so.
Siro
Schade eigentlich, für mich klang das sehr plausibel.
Dann sollte ich den Text mal lieber wieder löschen, sonst glaubt das noch jemand so.
Siro
Hallo
Laß den Text mal besser stehen. Auch wenn's noch nicht stimmt würde der Thread durchs Löschen zu sehr zerrissen. Nettes Grundlagenthema finde ich übrigends.
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Siro,
du solltest dir wirklich mal ernsthaft Gedanken um dein grundsätzliches Vorgehen machen. Ständig probierst du nur rum und ziehst dann aus deinen Beobachtungen deine eigenen Schlüsse, wie es sein könnte. Man kann eine Programmiersprache auf die Art nicht richtig lernen. Zum einen können diese Schlüsse schlicht falsch sein (was sie ja auch schon mehrfach waren), zum anderen hat jede Sprache irgendwelche Grundregeln, die man sich fast unmöglich auf diese Art selbst "erarbeiten" kann. Und warum sollte man das auch überhaupt erst probieren, wo doch der richtige Weg nicht nur zuverlässiger, sondern auch schneller ist. In der Zeit, die du bisher mit deinen "Eigenforschungen" verbracht hast, hättest du mit Sicherheit auch locker ein C-Buch sorgfältig durcharbeiten können. "Herumprobieren" ist höchstens sinnvoll, um zu überprüfen, ob man alles richtig verstanden hat. Und wenn ich dann noch daran denke, dass es bei dir nicht um eine Freizeitbeschäftigung geht, sondern um deinen Job ....
Zum Thema:
'<' ist ein normaler Operator wie auch '+', '-', etc. Das bedeutet, dass für ihn auch die Integer-Promotion-Rules gelten. Im wesentlichen ist das:
1) Die Typen der Operanden werden auf die selbe Größe gebracht. Der Größte "gibt den Takt vor", mindestens aber int.
2) Haben die Typen bereits die selbe Größe, aber eine unterschiedliche Signedness, wird in unsigned gerechnet.
Bei den int-Operanden sorgt 2) für das unerwartete Ergebnis.
Bei den short-Operanden spielt 2) keine Rolle mehr, nachdem 1) angewendet wurde.
MfG
Stefan
Naja, hättest ruhig sagen können, daß es ziemlicher Blödsinn ist, was ich geschrieben habe.
So hätte ich es mir vielleicht gedacht, aber so funktioniert es nunmal nicht.
Also ich versuche es noch einmal und werde jede Aussage separat halten, so könnt Ihr mir ein Sternchen vergeben wenn die Aussage richtig ist.
Ich möchte es ja einfach nur verstehen.
Der Standard Datentyp in "C" ist "int"
Wie groß ein "int" ist, hängt vom System ab.
Es können KEINE, weder logische noch mathematische Operation mit Werten durchgeführt werden, die eine kleinere Rangfolge haben als ein "int".
Die Rangfolge entspricht dem Speicherbedarf. ??? mach ich mal 3 Fragezeichen, ist das so ???
Aus einem char (8 Bit, unabhängig davon ob signed oder unsigned) wird vor einer logischen oder mathematischen Funktion ein "int"
Aus einem short (16 Bit, unabhängig davon ob signed oder unsigned) wird vor einer logischen oder mathematischen Funktion ein "int"
unter der Vorraussetzung, daß der Datentyp "short" eine geringere Rangfolge hat als der "int".
Werden 2 "int" Werte in eine logische oder mathematische Operation verwickelt, wovon einer der beiden ein unsigned ist,
wird der zweite Operand (der eigentlich signed ist) zu einem unsigned.
Habe den Text übrigens vor deinem letzten Beitrag (von sternst) geschrieben. Hab mich den ganzen Tag mit bescchäftigt, sogar den Assembler Code zerpflückt.
Danke nochmal.
Korrektur 30.11.2011
Stimmt irgendwie alles nicht, wie ich grad feststellen muste. Die Beschreibung lässt doch sehr zu wünschen übrig, wie die Integer Promotion funktioniert oder funktionieren sollte.
Rechnen tut er "oftmals" richtig, aber vergleichen geht ständig schief. Das Verhalten wird immer merkwürdiger.......
Hab auch keinen Bock mich weiterhin mit diesem Blödsinn auseinanderzusetzen, zumal mein Controller Vorzeichenrichtig in Hardware vergleichen kann, aber C baut einen derartigen Code herum, daß es nicht mehr funktioniert.
In Assembler läuft es einwandfrei.
Die einzige Möglichkeit welche ich gefunden habe, damit der C-Code wieder richtig funktioniert, ist die explizite Typwandlung vor dem Vergleich. Ansonsten ist das Ergebnis "UNDEFINIERT"
bzw. Compiler (Prozessor) spezifisch, also:
if (signed(a) > signed (b)) ......
Siro
Geändert von Siro (30.11.2011 um 19:48 Uhr)
geschlossen.
Geändert von Siro (08.12.2011 um 16:24 Uhr)
Lesezeichen