Hallo zusammen, habe ein kleines Verständnisproblem mit AVR C. Schreibe Programme in Bascom und möchte auf AVR Studio umsteigen. Und zwar verstehe ich folgendes nicht so richtig: a = 0x10000F23 a = (a << 3) Was passiert hier genau und was steht danach in der Variablen a? Wird danach nur Bit 3 der hexadezimalen Zahl von a in a stehen? VG Franz
:
Gesperrt durch Moderator
Franz schrieb: > Und zwar verstehe ich folgendes nicht so richtig: > > a = 0x10000F23 > a = (a << 3) > > Was passiert hier genau Nichts. Außer einer mehr oder weniger kryptischen Fehlermeldung des Compilers. Da fehlen Semikolons... > und was steht danach in der Variablen a? Na was schon: 0x10000F23 << 3, also 0x80007918. Wie das dann interpretiert wird, hängt vom Typ ab, mit dem a deklariert ist.
Franz schrieb: > a = (a << 3) > Was passiert hier genau Vermutlich das gleiche, wie wenn du in BASCOM schreibst
1 | SHIFT a, LEFT, 3 |
Franz schrieb: > AVR C. Es gibt keine spezielles "AVR C":-) Das sind ganz normale basics der Programiersprache C/C++ die überall gelten und die man daher schon kennen sollte wenn man diese Sprache nutzen will. https://en.cppreference.com/w/c/language/operator_arithmetic -> Shift operators
Irgend W. schrieb: > Das sind ganz normale basics der Programiersprache C/C++ die überall > gelten und die man daher schon kennen sollte wenn man diese Sprache > nutzen will. Na wo kommen wir denn da hin? Man soll die Sprache lernen, bevor man sie benutzt? Das geht ja mal garnicht, das macht ja Arbeit und erfordert eigene Denkleistung... Nö, das ist nicht mehr zeitgemäß...
Franz schrieb: > Was passiert hier genau und was steht danach in der Variablen a? > a = 0x10000F23 Das ist eine Zuweisung. Hier wird der angegebene Zahlenwert in die Variable a gespeichert. Wobei das "0x" die Zahl als hexadezimal-Zahl kennzeichnet. 0x10000F23 (hexadezimal) = 268439331 (dezimal) = 0b10000000000000000111100100011 (binär) > a = (a << 3) Das ist eine Schiebe-Operation. Alle Bits werden 3x nach links geschoben.
1 | Anfangswert ---10000000000000000111100100011 |
2 | 1x Schieben --10000000000000000111100100011- |
3 | 2x Schieben -10000000000000000111100100011-- |
4 | 3x Schieben 10000000000000000111100100011--- |
Die mit "-" gekennzeichneten Lücken werden mit 0 gefüllt.
Franz schrieb: > a = 0x10000F23 > a = (a << 3)
1 | unsigned long a; |
2 | a = 0x10000F23; // 0b0000010000000000000000111100100011 |
3 | a <<= 3; // 0b0010000000000000000111100100011000 |
Tipp: Wenn man wissen möchte, was ein Ausdruck tut, dann schaut man sich die Sprach Definition an. Alternativ, beschafft sich ein gutes Buch, welches einem die Sprache erklärt. Hier sollte jedes C oder C++ Grundlagenbuch geeignet sein. Egal wie alt. Dann probiert man das aus.... Aus dem Buch weiß man ja schon, was herauskommen sollte, und wenn es dann wirklich genau so herauskommt, dann besteht die Hoffnung, dass man ein klein wenig des Buches, der Sprache, verstanden hat.
Danke, an die mehr oder weniger konstruktiven Antworten! Das hat mir weitergeholfen. In Zusammenhang mit dem Codeschnippsel, den ich aus einem Programm hatte, war ich als Gelegenheitsprogrammierer auf dem Holzweg und stand gleichzeitig noch auf dem Schlauch. Es ging um das Beschreiben des 32 Bit CAN Registers CANIDT im AT90CAN128. Darin sind die nur die oberen 29 Bit beschrieben, weshalb die ID um 3 Bit nach links geshiftet werden muss. Das wurde mir jetzt erst durch eure Hilfe und nach dem Wälzen des Datenblattes bewusst. Mit der Bascom Bibliothek war das Shiften nicht notwendig. VG Franz
Franz schrieb: > Es ging um das Beschreiben des 32 Bit Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu schreiben. Unsigned long ist nämlich nicht genau definiert da plattformabhängig. Es ist einfach schlechter Stil.
Perfekt, danke für den Hinweis! Hatte ich bereits so umgesetzt.
Nick M. schrieb: > Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu > schreiben. > Unsigned long ist nämlich nicht genau definiert da plattformabhängig. > Es ist einfach schlechter Stil. Zu unsigned long sagt mein Lieblingsbuch > at least 32 Bit Zu uint32_t sagt es: > provided only if the implementation directly supports the type Also, wie du darauf kommst, dass unsigned long jetzt schlechter Stil ist, kann ich beim besten Willen nicht erkennen. Zumindest gibt es das immer, und es hat die hier geforderten 32Bits, mindestens. Wobei es das uint32_t offensichtlich nicht immer geben muss. Also baut man sich mit uint32_t einen Plattformabhängigen Bug ins Getriebe. Im Prinzip also genau das Gegenteil, von dem was du erreichen möchtest. Nein, aus der Sicht/Perspektive ist uin32_t die falsche Wahl und dem entsprechend schlechter Stil.
Arduino Fanboy D. schrieb: > Zu unsigned long sagt mein Lieblingsbuch >> at least 32 Bit Also auch mehr. Nochdazu ist das mit unsigned char, long, ... dermaßen angestaubter C&R Stil, dass ich nur mal dezent empfehlen kann aktuelle Programme anzusehen. Nach bald 50 Jahren C kann man das schon mal verlangen. Arduino Fanboy D. schrieb: > Zu uint32_t sagt es: >> provided only if the implementation directly supports the type Wenn nicht vorhanden geht es nicht. Wäre schlecht wenn es 32 Bit Peripherie-Register gäbe. Folglich gibt es die Typen die man braucht. Arduino Fanboy D. schrieb: > Wobei es das uint32_t offensichtlich nicht immer geben muss. Die gibt es (s.o.) genau dann wenn sie benötigt werden. Wenn es den uint32_t nicht gibt, dann wird sich der Compiler schon melden. Bei unsigned long denkt sich der Compiler halt was Anderes wie du. Und du bist dann garantiert unglücklich darüber. Arduino Fanboy D. schrieb: > kann ich beim besten Willen nicht erkennen. Deine persönlichen Fähigkeiten sind aber nicht ausschlaggebend.
Arduino Fanboy D. schrieb: > Wobei es das uint32_t offensichtlich nicht immer geben muss. Wenn es uint32_t nicht gibt, dann ist entweder dein Compiler antik, du hast keine stdint.h / cstdint eingebunden, oder deine CPU kann schlicht nicht mit 32 Bit umgehen (auch nicht per Emulation).
S. R. schrieb: > Wenn es uint32_t nicht gibt, dann ist entweder dein Compiler antik, du > hast keine stdint.h / cstdint eingebunden, oder deine CPU kann schlicht > nicht mit 32 Bit umgehen (auch nicht per Emulation). "Ich" weiß das. "Ich" weiß sogar, dass es völlig egal ist, ob man beim avr-gcc uint32_t schreibt oder unsigned long. Denn, wie du schon sagst, der gcc und seine stdint.h gibt das her. Aber dann darf man nicht von Plattform unabhängig sprechen, wenn es eben doch von der Plattform abhängig ist. Ich weiß nicht, wie man das anders sehen kann, aber ich sehe da zumindest einen Widerspruch drin, evtl. auch einen Irrtum, die Unwahrheit und mit zunehmender Wiederholung auch eine Lüge. In dem Posting von muellernick stecken 2 Irrtümer. 1. ihm bezeichnet uint32_t als Plattform unabhängig 2. ihm meint, seinen Stil anderen aufzudrücken zu müssen Punkt 2 interessiert mich nicht. Da darf jeder hackstücken, wie es beliebt. OK, ein irgendwie gelagertes Priestertum, nervt auch schon etwas. Nur nicht Stilfragen mit Unwahrheiten begründen, da fehlt mir die Toleranz. In Stilfragen ist sowieso schon schwer Gleichschaltung zu erreichen, wenn da dann noch Unwahrheiten mit rein spielen.... Punkt 1, der ist schon halbwegs wichtig, wenn man über den AVR Tellerrand hinausblickt. Eben möglichst plattformneutral arbeiten möchte. Und da liegt muellernick faktisch falsch. Habe ihn darauf hingewiesen. Zeigt sich völlig uneinsichtig. Es geht also, über einen einfachen Irrtum, hinaus.
Arduino Fanboy D. schrieb: > 1. ihm bezeichnet uint32_t als Plattform unabhängig Was denkt ES sei daran falsch? Meint DAS dass uint_32 unterschiedlich lang sei, so wie long? Arduino Fanboy D. schrieb: > 2. ihm meint, seinen Stil anderen aufzudrücken zu müssen Ihm kannst das machen wie ohm will. Her schlage ich jedoch vor: #define fanboyint long Damit kann she versuchen was sich besser durchsetzt. Derweilen überlege tu welche abscheuliche Gleichschaltung doch stdint ist E-KEL-HAFT!
Hallo Arduino Fanboy, Aber leider ist es nicht so, wie Du denkst. Ja, unsigned long kann identisch mit uint32_t sein, muss es aber nicht. Auf einem Atmel System ist ein int z.B. 8 Bit groß, auf einem Stm32 32 Bit. Ein int beschreibt die native Größe der Datenbreite des Systems. Davon abhängig sind alle weiteren Typen. Ein unsigned long bezieht sich also ebenfalls auf int und ist auf einer 8-Bit Architektur nicht so groß, wie auf einer 32-Bit Architektur und somit nicht Plattform unabhängig. Ein uint8_t wird überall 8 Bit breit seit, solange die Architektur damit umgehen kann. Genauso verhält es sich mit uint32_t und unsigned long. Die in der stdint.h beschriebenen Datentypen sind somit unabhängig von der Architektur, solange diese mit den Typen umgehen kann. Grüße
Ich Depp habe im Namensfeld angefangen zu schreiben. Tut mir leid dafür. Grüße Max
Noch was hinterher, sonst greift die Verdummung nur noch weiter um sich. Arduino Fanboy D. schrieb: > ob man beim avr-gcc uint32_t schreibt oder unsigned long. > Denn, wie du schon sagst, der gcc und seine stdint.h gibt das her. Schön, nur ist das mit dem long so, dass es je nach Plattform eine andere Länge haben kann, im Gegensatz zu uint32_t. > Aber dann darf man nicht von Plattform unabhängig sprechen, wenn es > eben doch von der Plattform abhängig ist. long ist abhängig von der Platform. uint32_t ist überall gleich lang, das ist der Grund warum uint32_t Plattforunabhängig ist. > Ich weiß nicht, wie man das anders sehen kann, aber ich sehe da > zumindest einen Widerspruch drin, evtl. auch einen Irrtum, die > Unwahrheit und mit zunehmender Wiederholung auch eine Lüge. Ja, du lügst. Du versuchst wieder mal durch Lügen als Schlauberger dazustehen. > 2. ihm meint, seinen Stil anderen aufzudrücken zu müssen Deine C-Programme können aussehen wie du willst. Ich vermute mal, die wird sowieso sonst niemand sehen. > OK, ein irgendwie gelagertes Priestertum, nervt auch schon etwas. So wissen die Leutehalt untereinander besser was der Andere meint. int16_t ist halt überall genau 16 Bit lang. Beim int ist das aber komplett anders. Aber du beweist ja schon zu genüge, dass du zu vernünftigeer Kommunikation nicht fähig bist. > Nur nicht Stilfragen mit Unwahrheiten begründen, da fehlt mir die > Toleranz. Schreibtst du Tolleranz nicht mit zwei ll, so wie Looser mit zwei oo? Egal, wo hab ich eine Unwahrheit verbreitet? > Unwahrheiten Hab ich schon wieder die Unwahrheit gesprochen? Jetzt aber mit Zitat und Link. > Punkt 1, der ist schon halbwegs wichtig, wenn man über den AVR > Tellerrand hinausblickt. Ach, plötzlich ist das doch gar nicht so schlecht kein long zu verwenden? Kommt jetzt die Wende? > Und da liegt muellernick faktisch falsch. > Habe ihn darauf hingewiesen. Du weißt mich darauf hin long zu verwenden? Ich sags nochmal, es ist besser int32_t zu verwenden, weil dann jeder weiß was gemeint ist. "Sprechend programmieren" nennt sich das. Ich weiß morgen schon nicht mehr, wie die Registerbreite eines AVR (wecher denn?) ist. > Zeigt sich völlig uneinsichtig. Jep! So wie Millionen andere C-Programmierer. > Es geht also, über einen einfachen Irrtum, hinaus. Lass die Unterstellungen die du Grabhausfunsel nicht belegen kannst.
Nick M. schrieb: > E-KEL-HAFT! Sind wir schon wieder beim Ich-und-Du? Kaum zu glauben, dass hier erwachsene Menschen miteinander diskutieren... Stefan ⛄ F. schrieb: > 0x10000F23 (hexadezimal) = 268439331 (dezimal) = > 0b10000000000000000111100100011 (binär) An dieser Stelle empfehle ich, nicht den umständlichen Umweg über die Dezimalzahl zu machen, sondern einfach die Hexzahl Nibble für Nibble direkt in die Binärzahl abzubilden:
1 | hex binär |
2 | 0 = 0000 |
3 | 1 = 0001 |
4 | 2 = 0010 |
5 | 3 = 0011 |
6 | 4 = 0100 |
7 | : |
8 | : |
9 | D = 1101 |
10 | E = 1110 |
11 | F = 1111 |
12 | |
13 | --> |
14 | |
15 | 0x 1 0 0 0 0 F 2 3 |
16 | 0b 0001 0000 0000 0000 0000 1111 0010 0011 |
Dann muss man auch links nichts mehr "auffüllen", denn die Nullen sind beim stupiden "Umzeichnen" (denn von "Umrechnen" kann da keine Rede mehr sein) schon reingekommen. Letztlich muss man sich dann also nur 16 solcher 4-Bit-Muster merken und ist fürderhin ein "Blitzumrechner" von Bin nach Hex und umgekehrt. Und dann tauchen auch nicht auf einmal noch 2 zusätzliche verwirrende führende Bits im Kommentar auf, so wie Arduino Fanboy D. schrieb: > a = 0x10000F23; // 0b0000010000000000000000111100100011
Lothar M. schrieb: >> E-KEL-HAFT! > Sind wir schon wieder beim Ich-und-Du? Habs ja versucht, wie der fanboy, "ihm" zu verwenden. Aber irgendwie kommt mir das so Regenbogen vor, dass mir ekelt. Wenn du aber den Inhalt der Postings einzig durch die Anzahl der "Du" bewertest, würde ich dir doch mal nahelegen den hahnebüchernen Quatsch vom Fanboy genauer zu lesen. Und vor allem bitte auch nachvollziehen wie er wieder ausgeflippt ist. Hier ging es los: Beitrag "Re: Verständnisproblem in AVR C Syntax" Da siehst du auch wieder wie hier fachliche neutrale Inhalte bewertet werden (mit -2 Punkten). Denen geht es mehr ums prahlen. Mir nicht, darum trage ich alle Minuspunkte als Auszeichnung. :-)
Nick M. schrieb: > Da siehst du auch wieder wie hier fachliche neutrale Inhalte bewertet > werden Der Ton macht die Musik. Und eure "Musik" ist atonaler Lärm und Krach. So wie wenn zwei Kinder auf Töpfen herumtrommeln um einander zu übertönen. > Und vor allem bitte auch nachvollziehen wie er wieder ausgeflippt ist. Wann immer man auf einen anderen zeigt, zeigen 3 Finger zurück. > Wenn du aber den Inhalt der Postings einzig durch die Anzahl der "Du" > bewertest Ich bewerte die Sachlichkeit an der Anzahl von Personalpronomen. Dazu gehören neben ich und du auch mein, sein, dir, ihm, ihr usw. Denn wenn die Überhand gewinnen, kann es nicht mehr um "die Sache" gehen. > darum trage ich alle Minuspunkte als Auszeichnung. Jetzt bitte nicht auch noch den Märtyrer heraushängen...
Lothar M. schrieb: > An dieser Stelle empfehle ich, nicht den umständlichen Umweg über die > Dezimalzahl zu machen, sondern einfach die Hexzahl Nibble für Nibble > direkt in die Binärzahl abzubilden: Ich empfehle, einen Taschenrechner zu benutzen, den entfällt nicht nur der "Umweg" sondern auch das Kopfrechnen.
Stefan ⛄ F. schrieb: > Ich empfehle, einen Taschenrechner zu benutzen, den entfällt nicht nur > der "Umweg" sondern auch das Kopfrechnen. Und man setzt sich auch nicht der Gefahr aus, ein "Gefühl" für diese Zahlen zu bekommen. Es ist z.B. auch hilfreich zu wissen, dass 2^10 etwa 1000 sind (genau 1024) oder 2^20 etwa 1 Million (genauer 1024*1024) und 2^30 etwa 1 Milliarde (exakt 1024*1024*1024). Wenn man das weiß, dann kann man sein Taschenrechnerergebnis auch schnell mal auf Plausibilität bzw. Tippfehler "kontrollieren". Aber du hast Recht, es geht auch mit dem Taschenrechner.
Lothar M. schrieb: > Ich bewerte die Sachlichkeit an der Anzahl von Personalpronomen. Dazu > gehören neben ich und du auch mein, sein, dir, ihm, ihr usw. Denn wenn > die Überhand gewinnen, kann es nicht mehr um "die Sache" gehen. Keine Ahnung wo andere Teilnehmer wohnen. Unsereins wohnt in Bayern. Und da ist es so, dass man die Leute mit denen man spricht mit Du oder Sie anredet. Ganz egal ob das der Müllfahrer oder der Arzt ist. Wir betrachten das als Form der Höflichkeit. Wenn das in anderen Regionen Deutschlands als höflich angesehen wird Leute nicht direkt anzusprechen: Bei uns ist das eine Beleidigung. Lothar M. schrieb: >> Und vor allem bitte auch nachvollziehen wie er wieder ausgeflippt ist. > Wann immer man auf einen anderen zeigt, zeigen 3 Finger zurück. Ach, solch Moralin-triefende Sprüche! Es fehlt noch einer: Der Klügere gibt nach (bis er der Dümmere ist). Lothar M. schrieb: >> darum trage ich alle Minuspunkte als Auszeichnung. > Jetzt bitte nicht auch noch den Märtyrer heraushängen... Bin kein Märtyrer. Ich lass mir nur nichts gefallen.
Arduino Fanboy D. schrieb: > Aber dann darf man nicht von Plattform unabhängig sprechen, wenn es eben > doch von der Plattform abhängig ist. Es kommt darauf an, was man unter "Plattform" versteht. Da gibt es zwei Möglichkeiten: - C-Compiler als "Plattform" Hier könnte ein anderer C-Compiler als gcc durchaus eine andere Auffassung über die Breite eines "unsigned long" haben. Ich weiß, dass es AVR-C-Compiler gibt, die mit einem 8-Bit-breiten "int" arbeiten. Von daher wäre die Verwendung eines uint32_t unabhängig vom C-Compiler und damit portabler. - Hardware als "Plattform" Das CAN Registers CANIDT im AT90CAN128 ist 32 Bit breit. Von daher empfiehlt sich auch hier die Verwendung eines uint32_t, um portabel zu sein. Ein unsigned long könnte bei Wechsel des Compilers zu Problemen führen. Fazit: Wie man es auch dreht und wendet: Die Verwendung von uint32_t ist hier angesagt - egal, ob man als "Plattform" den C-Compiler oder die Hardware sieht. Hlllo Arduino Fanboy schrieb: > Auf einem Atmel System ist ein int z.B. 8 Bit groß, Falsch. Es sind 16 Bit. Jedenfalls beim avr-gcc.
Frank M. schrieb: > Hlllo Arduino Fanboy schrieb: >> Auf einem Atmel System ist ein int z.B. 8 Bit groß, > > Falsch. Es sind 16 Bit. Jedenfalls beim avr-gcc. Solange man in nicht mit "-mint8" dazu überredet, die C-Regel "int hat min. 16bit" zu missachten.
Frank M. schrieb: >> Auf einem Atmel System ist ein int z.B. 8 Bit groß, > > Falsch. Es sind 16 Bit. Jedenfalls beim avr-gcc. Das ist dieser Mist mit dem int und long und ... Ein int ist 2 Bytes oder 4 Bytes lang. Üblicherweise. Man hat das historisch bedingt komplett vermurkst. Seit C99 (sehr oft aber auch in Nicht-C99 übernommen) ist das ordentlich definiert. X ist 8, 16, 32, 64 (das stimmt so nicht ganz) intX_t & uintX_t: So breit wie angegeben. int_leastX_t & uint_leastX_t: Der Compiler sucht sich das raus was ihm am liebsten ist. int_fastX_t & uint_fastX_t: Vom Compiler gewähltes X darf größer sein, falls der Prozessor das schneller verarbeiten kann. intmaxX_t & uintmaxX_t: Der größte int der implementiert ist. intptr_t & uintptr_t: Int der groß genug ist einen Pointer aufzunehmen. Man sieht, da hat man sich einiges dazu überlegt. Und das sollte man dann auch besonders beim µC verwenden. Bei floats ist alles klar geregelt.
Carl D. schrieb: > Solange man in nicht mit "-mint8" dazu überredet, die C-Regel "int hat > min. 16bit" zu missachten. LOL! Cool! Ein Grund mehr für uint_16 und Konsorten.
Nick M. schrieb: > Nochdazu ist das mit unsigned char, long, ... dermaßen angestaubter C&R > Stil, dass ich nur mal dezent empfehlen kann aktuelle Programme > anzusehen. Nach bald 50 Jahren C kann man das schon mal verlangen. Da sehe ich nichts angestaubtes drin. Festbreitentypen wie uint32_t sind dafür gedacht, dass man sie genau dann nutzt, wenn es essenziell ist, dass der Typ exakt 32 Bit breit ist und auf gar keinen Fall größer oder kleiner. Bei der Berechnung, um die es hier geht, entsteht aber kein Fehler, wenn der Wert größer ist als 32 Bit, also ist uint32_t nicht der am besten geeignete Typ, da er unnötig stark einschränkt. > Arduino Fanboy D. schrieb: >> Wobei es das uint32_t offensichtlich nicht immer geben muss. > > Die gibt es (s.o.) genau dann wenn sie benötigt werden. Wenn es den > uint32_t nicht gibt, dann wird sich der Compiler schon melden. Bei > unsigned long denkt sich der Compiler halt was Anderes wie du. Also zumindest ich denke bei unsigned long, dass ich einen Typ haben will, der mindestens 32 Bit breit ist. Genau das gibt mir der Compiler. Arduino Fanboy D. schrieb: > Punkt 1, der ist schon halbwegs wichtig, wenn man über den AVR > Tellerrand hinausblickt. Eben möglichst plattformneutral arbeiten > möchte. > Und da liegt muellernick faktisch falsch. > Habe ihn darauf hingewiesen. > Zeigt sich völlig uneinsichtig. > > Es geht also, über einen einfachen Irrtum, hinaus. Es gibt neben den Basistypen und uint32_t auch noch weitere typedefs in stdint.h, nämlich uint_least32_t und uint_fast32_t. Die finden in der Praxis leider eher wenig Beachtung, sind aber eigentlich genau dafür da. Ersteres ist der kleinstmögliche Typ, der mindestens 32 Bit hat, zweiteres der schnellste mit mindestens 32 Bit. So kann man je nachdem, ob einem der Speicher oder die Laufzeit wichtiger ist, den passenden Typ wählen und sich dabei gleichzeitig nicht auf die exakten 32 Bit festzurren. Hlllo Arduino Fanboy schrieb: > Ja, unsigned long kann identisch mit uint32_t sein, muss es aber nicht. > Auf einem Atmel System ist ein int z.B. 8 Bit groß, Das kann man optional in GCC so einstellen, ist aber nicht standardkonform. int muss immer mindestens 16 Bit breit sein. > Ein int beschreibt die native Größe der Datenbreite des Systems. Er sollte möglichst die native Größe beschreiben, aber das ist laut Standard nicht verpflichtend. Auf 64-Bit-Systemen wird das meistens auch nicht gemacht. Dort ist int dann trotzdem 32 Bit breit, einfach weil man sonst zu wenig Typen für die gängigeren kleineren Größen hätte. > Davon abhängig sind alle weiteren Typen. Ein unsigned long bezieht sich > also ebenfalls auf int long muss mindestens 32 Bit breit sein und darf nicht kleiner sein als int. Nick M. schrieb: > long ist abhängig von der Platform. uint32_t ist überall gleich lang, > das ist der Grund warum uint32_t Plattforunabhängig ist. long existiert auf jeder Plattform und ist auf jeder Plattform mindestens 32 Bit breit. Ob uint32_t existiert, hängt von der Plattform ab. > So wissen die Leutehalt untereinander besser was der Andere meint. > int16_t ist halt überall genau 16 Bit lang. Beim int ist das aber > komplett anders. Die spannene Frage ist doch: Wie oft brauchst du in der Praxis überhaupt die Zusicherung, dass der Typ wirklich exakt 16 Bit hat und auf gar keinen Fall mehr? Mir fallen da im Wesentlichen zwei Stellen ein: Hardware-Register und binäre Kommunikation (über eine Schnittstelle oder eine Datei). Da spielt das aber auch nur auf unterster Ebene eine Rolle. Nick M. schrieb: > Keine Ahnung wo andere Teilnehmer wohnen. Unsereins wohnt in Bayern. Und > da ist es so, dass man die Leute mit denen man spricht mit Du oder Sie > anredet. Ganz egal ob das der Müllfahrer oder der Arzt ist. Wir > betrachten das als Form der Höflichkeit. Wenn das in anderen Regionen > Deutschlands als höflich angesehen wird Leute nicht direkt anzusprechen: > Bei uns ist das eine Beleidigung. Es geht wohl nicht darum, ob man sie benutzt, um jemanden anzusprechen, sondern eher darum, wie häufig diese Wörter in einer technischen Diskussion vorkommen. Wenn sie sich sehr häufen, liegt der Verdacht nahe, dass man mehr über einander diskutiert (aka. Flamewar) als über das eigentliche Thema. Nick M. schrieb: > X ist 8, 16, 32, 64 (das stimmt so nicht ganz) Richtig. Denn auf einem DSP, der nur in Vielfachen von 24 Bit arbeiten kann, kann X auch 24 sein. Dann gibt's halt die [u]intX_t für die von dir angegebenen Größen nicht, aber einen [u]int24_t. Die least- und fast-Typen gibt es trotzdem für die von dir angegebenen Größen. Das ist deren Vorteil. > int_leastX_t & uint_leastX_t: Der Compiler sucht sich das raus was ihm > am liebsten ist. Nein, er nimmt das kleinste, was mindestens X Bits hat. > Bei floats ist alles klar geregelt. Nö.
:
Bearbeitet durch User
Nick M. schrieb: > Keine Ahnung wo andere Teilnehmer wohnen. Unsereins wohnt in Bayern. Und > da ist es so, dass man die Leute mit denen man spricht mit Du oder Sie > anredet. Ganz egal ob das der Müllfahrer oder der Arzt ist. Wir > betrachten das als Form der Höflichkeit. Wenn das in anderen Regionen > Deutschlands als höflich angesehen wird Leute nicht direkt anzusprechen: > Bei uns ist das eine Beleidigung. Und wie ist es mit "das Mensch"? War mal ein bayrischer Ausdruck. Verwende ich nicht, komme aus Franken!
Rolf M. schrieb: > Nick M. schrieb: >> long ist abhängig von der Platform. uint32_t ist überall gleich lang, >> das ist der Grund warum uint32_t Plattforunabhängig ist. > > long existiert auf jeder Plattform und ist auf jeder Plattform > mindestens 32 Bit breit. Ob uint32_t existiert, hängt von der Plattform > ab Es geht aber um exakte Länge. Wenn man wenig Platz hat kann das essentiell sein. Es geht auch darum (Stilfrage) Anderen mitzuteilen, dass es explizit 32 Bit sind die die Daten vollständig und ohne Platzverschwendung darstellen können. Am PC mag das nicht relevant sein. Es geht nochmal um die exakte Länge. Stell dir eine Datenübertragung vor. Es dient niemanden wenn der long mal länger ist, die Gegenseite wird Mist lesen. Oder die Gegenseite naiverweise auch ein long verwendet, obwohl die einen 64-Bit Prozessor hat. Es geht nochmal um die exakte Länge wenn man z.B. einen Wert in ein EPROM schreiben will. Oder per seek() in eine Datei schreiben will. Das kann bei einer Portierung fatal ausgehen. Ich sehe einfach keinen Gewinn darin solche Zeitbomben im Code zu vergraben. Rolf M. schrieb: >> X ist 8, 16, 32, 64 (das stimmt so nicht ganz) > > Richtig. Denn auf einem DSP, der nur in Vielfachen von 24 Bit arbeiten > kann, kann X auch 24 sein. Dann gibt's halt die [u]intX_t für die von > dir angegebenen Größen nicht, Das war das mit dem "stimmt so nicht ganz" Die Längen 8, 16, 32 und 64 müssen bei int_least und int_fast implementiert sein. Jedoch kann (und wird) der Compiler was größeres bei intX_t nehmen. Ich hab schon gesehen, dass du intX_t geschrieben hast! Rolf M. schrieb: >> int_leastX_t & uint_leastX_t: Der Compiler sucht sich das raus was ihm >> am liebsten ist. > > Nein, er nimmt das kleinste, was mindestens X Bits hat. Da hab ich mich schlecht ausgedürckt. Der Compiler nimmt das, was mindestens X Bit hat. "An integer type whose width is at least X bits." >> Bei floats ist alles klar geregelt. > > Nö. Nach IEC 60559 schon. Muss der Compiler aber nicht implementieren, insofern hast Du recht. (Makro
1 | __STDC_IEC_559__
|
nicht definiert)
Ich antworte dir, weil du mich direkt angesprochen hast..... Frank M. schrieb: > Von daher wäre die Verwendung eines uint32_t unabhängig vom C-Compiler > und damit portabler. Du möchtest mir sagen, dass die Verwendung eines Datentyps, welche nicht auf jeder Maschine existiert, portabler ist, als ein Datentype der die Mindestanzahl Bits die man braucht garantiert. Habe ich das richtig verstanden? Auch das -mint8, hat meiner Ansicht nach nichts mit Plattform unabhängig zu tun. Das ist eine Gcc Extrawurst, mit der man sich selbst außerhalb des Standards befördert. Selbst die mitgelieferte Libc versagt dann. Das -mint8 halte ich bei dieser Diskussion für eine Nebelkerze. Ich habe ja nichts dagegen, wenn einer uint32_ verwendet. Alles gut. Das mag in der kleinen AVR Welt sogar die "schönere" Variante sein... Allerdings: Der Kollege, dessen Namen ich nicht nenne werde, hat die Behauptung aufgestellt, dass die uint32_t besserer Stil ist, weil es Plattform unabhängig ist. Genau die Behauptung, dass unt32_t Plattform unabhängig ist, ist eine Lüge. Sollte in jedem halbwegs brauchbaren C und C++ Buch nachlesbar sein. Wem sollte man glauben, der Doku, oder einer erkannten Unwahrheit? Es ist unlogisch, sich auf seinen AVR Tellerrand zu berufen und von der Position dann über "Plattform Unabhängigkeit" zu schwadronieren. Ja, dann könnte man auch sagen: Die Erde ist eine Scheibe. Denn da wo ich stehe, sieht sie total platt aus. Ich denke, das scheint die beste Lösung für diesen Streit zu sein: Vielleicht sollte man den Begriff "Plattform unabhängig" mal neu definieren, in eurem Sinne. Oder einen anderen Begriff verwenden. Oder die Sprachdefinition umschreiben. Ach, sofort alles Sprachstandards unbesehen in die Tonne stopfen... --------- Betrachtet man nur AVR-gcc, ist die ganze "Portabilität" Diskussion sowieso überflüssig. unsigned long und uint32_t sind da identisch. Das gilt sicherlich auch für die meisten 32Bit Maschinchen/Compiler Wenn man den Standard fragt: > Welches ist der kleinstmögliche und vorzeichenlose Datentype, > der mir mindestens den Raum bietet, um 32 Bit Werte > zurecht zu dengeln? Dann lautet die Antwort: unsigned long Legt man Wert, auf möglichst weit reichende Portabilität, darf man eben nicht uint32_t nehmen, weil es eben nicht garantiert auf jedem Kesselchen existiert. Zudem, ist es auch für die Performance meist ganz gut, wenn man den Prozessor, möglichst mit seinen "natürlichen" Datentypen operieren lässt. z.B. einen 64Bit Rechner nicht zwingt uint32_t zu emulieren Die paar überflüssigen Bit tun keinem weh, kosten keinen Takt mehr Und die Bits bastelt der Compiler meist an anderer Stelle sowieso rein. > alignment, padding Aber was solls, ich habe je eh keine Ahnung.... Ihr soll euer "recht" haben. Auch möchte ich euch herzlichst um Verzeihung bitten, dass ich eine andere Vorstellung von "Plattform Unabhängigkeit" habe, als ihr.
Franz schrieb: > Es ging um das Beschreiben des 32 Bit CAN Registers CANIDT im > AT90CAN128. Rolf M. schrieb: > Bei der Berechnung, um die es hier geht, entsteht aber kein Fehler, wenn > der Wert größer ist als 32 Bit, also ist uint32_t nicht der am besten > geeignete Typ, da er unnötig stark einschränkt. Da bin ich anderer Meinung. Wobei man das von Franz durchaus überlesen kann wenn man so spät einsteigt.
Arduino Fanboy D. schrieb: > dass unt32_t Plattform unabhängig ist Seit C99 gehört stdint zu den Standardbibliotheken: https://en.wikibooks.org/wiki/C_Programming/stdint.h https://en.wikibooks.org/wiki/C_Programming/Standard_libraries Und wenn es irgendein Compilerbauer in dem seither vergangenen viertel Jahrhundert nicht geschafft hat, diese Funktionalität zu implementieren (bzw. den nötigen Header mitzuliefern), dann gäbe mir das zu denken.
:
Bearbeitet durch Moderator
Arduino Fanboy D. schrieb: > Genau die Behauptung, dass unt32_t Plattform unabhängig ist, ist eine > Lüge. Lass es einfach bleiben. Wenn man genau 32 Bit schreiben muss und die Platform unterstützt es nicht, dann sagt es dir der Compiler. Du hast damit einen kapitalen Fehler vermieden und musst dir einen anderen Prozessor aussuchen. Wenn es mindestens 32 Bit sein müssen, dann nimmt man int_least32_t Arduino Fanboy D. schrieb: > Wenn man den Standard fragt: >> Welches ist der kleinstmögliche und vorzeichenlose Datentype, >> der mir mindestens den Raum bietet, um 32 Bit Werte >> zurecht zu dengeln? > Dann lautet die Antwort: unsigned long > > Legt man Wert, auf möglichst weit reichende Portabilität, darf man eben > nicht uint32_t nehmen, weil es eben nicht garantiert auf jedem > Kesselchen existiert. > > Zudem, ist es auch für die Performance meist ganz gut, wenn man den > Prozessor, möglichst mit seinen "natürlichen" Datentypen operieren > lässt. Was ist daran so schwer zu verstehen? Nick M. schrieb: > X ist 8, 16, 32, 64 (das stimmt so nicht ganz) > intX_t & uintX_t: So breit wie angegeben. > int_leastX_t & uint_leastX_t: Der Compiler sucht sich das raus was mindestens X breit ist (geändert) > int_fastX_t & uint_fastX_t: Vom Compiler gewähltes X darf größer sein, > falls der Prozessor das schneller verarbeiten kann. > intmaxX_t & uintmaxX_t: Der größte int der implementiert ist. > intptr_t & uintptr_t: Int der groß genug ist einen Pointer aufzunehmen.
Lothar M. schrieb: > Arduino Fanboy D. schrieb: >> dass unt32_t Plattform unabhängig ist > Seit C99 gehört stdint zu den Standardbibliotheken: > https://en.wikibooks.org/wiki/C_Programming/stdint.h > https://en.wikibooks.org/wiki/C_Programming/Standard_libraries > Und wenn es irgendein Compilerbauer in dem seither vergangenen viertel > Jahrhundert nicht geschafft hat, diese Funktionalität zu implementieren > (bzw. den nötigen Header mitzuliefern), dann gäbe mir das zu denken. Also mein Buch sagt: > provided only if the implementation directly supports the type Es gibt also keine Pflicht das zu implementieren. Dein Link sagt: > These types are optional unless the implementation supports > types with widths of 8, 16, 32 or 64, then it shall typedef > them to the corresponding types with corresponding N. > Any other N is optional[1] . Also recht gleichlautend. uint32_t wird implementiert, wenn der Prozessor/Compiler das von Hause aus kann. Sonst nicht. Es gibt keine Verpflichtung, da eine uint32_t Emulation zu implementieren. Die Gründe das frei zu halten, "könnten" im gleichen Bereich liegen, wie die Größe eines Byte, oder besser char, nicht festzulegen. uin32_t mag ja für viele Kesselchen ein natürlicher Datentype sein. Für einige andere allerdings nicht, z.B. die seltenen 9 Bit pro char Kesselchen. Dort geht uint32_t mit einem Mehraufwand einher. Es bleibt dem Compiler Ersteller überlassen, ob er es implementiert. uint32_t ist für 32 Bit Rechner ein natürlicher Datentype 8Bit Rechner werden in eine Emulation gezwungen 64Bit Rechner sicherlich auch. 9Bit Rechner werden es gar nicht haben, oder emulieren. Wie schon gesagt: Mein Begriff von "Plattform unabhängig" unterscheidet sich offensichtlich von manch anderen.
Arduino Fanboy D. schrieb: > Wie schon gesagt: > Mein Begriff von "Plattform unabhängig" unterscheidet sich > offensichtlich von manch anderen. "Ein Geisterfahrer? Hunderte!" Ja, offensichtlich verstehst du plattformunabhängig nicht wie die meisten Menschen als "liefert auf jeder Plattform das gleiche Ergebnis - oder einen Fehler" sondern als "läuft auf jeder Plattform, wenn auch mit unterschiedlichem Ergebnis". MfG, Arno
Es macht auf einem AVR8Bit sehr wohl einen Unterschied in der Performance, ob man für einen Zähler im Bereich 0-255 ein "uint8_t" oder ein "unsigned" benutzt. Letzteres zwingt den Compiler dazu unnötigerweise 16 bit Operationen zu machen. (Einfach auf den Assemblercode schauen, sieht man sofort) Der korrekte Weg um z.B. eine lokale Ganzzahlvariable zu deklarieren ist "[u]int_fast_[8|16|32|64]_t". Damit wird dem Compiler die Mindestgröße der Variable mitgeteilt und ihm gleichzeitig frei gestellt größere, der CPU Architektur besser passende Typen, zu verwenden. Ein uint_fast8_t hat auf einem AVR 8 Bit, auf einem MSP430 16Bit und auf ARM 32 Bit. Ganz anders sieht es aus wenn man Strukturen definiert. Hier sollte man mit "[u]int_least_[8|16|32|64]_t" arbeiten. Man gibt dem Compiler damit auch wieder die Mindestgröße in Bits vor und lässt ihn den kleinsten, von der Architektur unterstützten Datentyp wählen, der diese Anforderung erfüllt. Dadurch erreicht man das die Strukturen möglichst klein sind (= mehr freier Speicher) und parallel dazu aber die Beschränkungen der Platform automatisch berücksichtigt werden. Es gibt z.B. DSPs die können nicht Byteweise auf den Speicher zu greifen, da ist uint_least8_t dann z.B. 16 Bit groß. Wir haben hier in der Firma ne CPU die nicht mal 16 Bit kann.
Arno schrieb: > Ja, offensichtlich verstehst du plattformunabhängig nicht wie die > meisten Menschen als "liefert auf jeder Plattform das gleiche Ergebnis - > oder einen Fehler" sondern als "läuft auf jeder Plattform, wenn auch mit > unterschiedlichem Ergebnis". Du darfst da rein interpretieren, was du möchtest..... Allerdings ist die Kernaussage, meines ganzen Sermons hier: uint32_t als Plattform unabhängig zu bezeichnen ist falsch. Eine Unwahrheit, ein Irrtum, und bei Wiederholung eine Lüge. Die Doku gibt mir recht.
Nick M. schrieb: > Es geht aber um exakte Länge. Warum? > Wenn man wenig Platz hat kann das essentiell sein. Dann ist Patz sparen wichtig, nicht eine exakte Länge. Dann nimmt man uint_least32_t. Die least-Typen sind wie gesagt die Platzspartypen. > Es geht auch darum (Stilfrage) Anderen mitzuteilen, dass es explizit 32 > Bit sind die die Daten vollständig und ohne Platzverschwendung > darstellen können. Genau das sagt uint_least32_t am besten. > Es geht nochmal um die exakte Länge. Stell dir eine Datenübertragung > vor. Es dient niemanden wenn der long mal länger ist, die Gegenseite > wird Mist lesen. > Es geht nochmal um die exakte Länge wenn man z.B. einen Wert in ein > EPROM schreiben will. Oder per seek() in eine Datei schreiben will. Das > kann bei einer Portierung fatal ausgehen. Das hab ich doch geschrieben, dass man die Festbreitentypen genau für solche Sachen braucht. Da sind sie auch absolut sinnvoll, aber meiner Ansicht nach eben nur da. Ich würde nach diesem Schema vorgehen: [u]int_leastX_t: Wenn man eher Platz sparen will [u]int_fastX_t: Wenn man eher Zeit sparen will [u]int_X_t: Wenn eine Schnittstelle eine ganz bestimte Größe diktiert Und wenn alles 3 nicht zutrifft, kann man auch auf die klassischen char/short/long/long long zurückgreifen. Natürlich muss man sich dabei darüber bewusst sein, was die garantieren und was nicht.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Du möchtest mir sagen, dass die Verwendung eines Datentyps, > welche nicht auf jeder Maschine existiert, portabler ist, > als ein Datentype der die Mindestanzahl Bits die man braucht > garantiert. Wenn du eine Maschine benutzt, die keinen uint32_t kennt, dann kannst du ihn dir gern selbst definieren. Vernünftige Menschen benutzen vernünftige Datentypen, und das ist in der heutigen Zeit irgendwas mit einem garantierten Wertebereich. Ich bevorzuge Code, der bestimmte Fehler grundsätzlich vermeidet. Weder "int" noch "long" garantieren einen Wertebereich - sie garantieren ein minimales Maximum. Unsigned overflow ist definiertes Verhalten im Rahmen des Standards und daher auf diesen Datentypen beispielsweise wesentlich abhängiger von der Plattform als dein Beispiel. Diesmal hast du dich schlicht verrannt. Ich mag des Nick's Diskussionsstil auch nicht, aber hier blendet dich der Hass.
Arduino Fanboy D. schrieb: > Allerdings ist die Kernaussage, meines ganzen Sermons hier: > uint32_t als Plattform unabhängig zu bezeichnen ist falsch. Schöner Strohmann: Das hat ja auch niemand behauptet.
Hallo, Stefan ⛄ F. schrieb: > Ich empfehle, einen Taschenrechner zu benutzen, den entfällt nicht nur > der "Umweg" sondern auch das Kopfrechnen. Das ist doch nicht dein Ernst, oder? rhf
Arduino Fanboy D. schrieb: > Allerdings ist die Kernaussage, meines ganzen Sermons hier: > uint32_t als Plattform unabhängig zu bezeichnen ist falsch. > Eine Unwahrheit, ein Irrtum, und bei Wiederholung eine Lüge. > Die Doku gibt mir recht. Ich lese http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf so dass uint32_t 32 bit lang ist und Werte von 0 bis UINT32_MAX annehmen kann. Plattformunabhängig. Nach dem Standard ist uint32_t optional. uint_least32_t ist mindestens 32 bit lang und kann Werte von 0 bis UINT_LEAST32_MAX annehmen. Der Standard sagt nicht, dass uint_least32_t optional ist. ULONG_MAX, der Maximalwert von unsigned long int, ist laut Standard mindestens 4294967295. Ich bevorzuge inzwischen oft die fix definierten Typen (uint8_t etc), aber wenn die Bibliotheksfunktionen unsigned char, unsigned long oder so erwarten und liefern dann ist schön anders. Echte Plattformunabhängigkeit ist eh schwierig, zum Beispiel wenn es um Geschwindigkeit geht. LG, Sebastian
:
Bearbeitet durch User
Rolf M. schrieb: >> Es geht auch darum (Stilfrage) Anderen mitzuteilen, dass es explizit 32 >> Bit sind die die Daten vollständig und ohne Platzverschwendung >> darstellen können. > > Genau das sagt uint_least32_t am besten. Wenn es explizit 32 sein müssen ist uint_least32 falsch. Aber wir verstehen uns schon! Rolf M. schrieb: > Das hab ich doch geschrieben, dass man die Festbreitentypen genau für > solche Sachen braucht. Also Übereinstimmung. Die Diskussion ist wegen eines CAN Registers mit 32 Bit losgegangen. Rolf M. schrieb: > Ich würde nach diesem Schema vorgehen: Alles d'accord!
Nick M. schrieb: > Also Übereinstimmung. > Die Diskussion ist wegen eines CAN Registers mit 32 Bit losgegangen. Eigentlich ging es nur um folgende Berechnung: Franz schrieb: > a = 0x10000F23 > a = (a << 3) Eine 29-Bit-CAN-ID soll um drei Bit nach links geschoben werden. Dass das Ergebnis nachher in ein Register geschrieben wird, ist dafür eigentlich gar nicht relevant. Das heißt, für a würde ich uint32_t nicht als zwingend sehen, für das Register natürlich schon. Aber da die Aktion dazu dient, den Wert für das Register aufzubereiten, wäre uint32_t auch nicht ganz verkehrt. > Rolf M. schrieb: >> Ich würde nach diesem Schema vorgehen: > > Alles d'accord! Prima!
Arduino Fanboy D. schrieb: > Allerdings: > Der Kollege, dessen Namen ich nicht nenne werde, hat die Behauptung > aufgestellt, dass die uint32_t besserer Stil ist, weil es Plattform > unabhängig ist. > Genau die Behauptung, dass unt32_t Plattform unabhängig ist, ist eine > Lüge. wieso Lüge, vom MS x86 Rechner kommend hatten wir in C unsere eigenen #defines gemacht #define BYTE #define UBYTE #define WORD #define UWORD #define DWORD #define UDWORD #define QWORD #define UQWORD usw. das nun umzuschreiben zu #define int8_t #define uint8_t #define int16_t #define uint16_t #define int32_t #define uint32_t #define int64_t #define uint64_t das macht es definitiv Plattform unabhängiger, schliesslich laufen meine alten C-Routinen auch immer noch auf dem AVR > Sollte in jedem halbwegs brauchbaren C und C++ Buch nachlesbar sein. > Wem sollte man glauben, der Doku, oder einer erkannten Unwahrheit? als wenn in Dokus oder Bücher nicht nur Meinungen der Autoren vertreten werden, oder glaubst du ALLES nur weil es geschrieben steht?
[Off Topic] Liebe Leute, ich finde es schade wie sich der Umgangston in diesem Forum in den letzten Jahren entwickelt hat. Sich der Lüge zu zeihen oder andere persönliche Anwürfe scheinen inzwischen normal geworden zu sein. Mir fällt es zunehmend schwerer den ja fachlich interessanten Debatten (so wie dieser) mit Interesse zu folgen. Erkennen wir nicht mehr, wohlmeinend, die gute Absicht des Anderen? LG, Sebastian [/Off Topic]
S. R. schrieb: > Arduino Fanboy D. schrieb: >> Allerdings ist die Kernaussage, meines ganzen Sermons hier: >> uint32_t als Plattform unabhängig zu bezeichnen ist falsch. > > Schöner Strohmann: Das hat ja auch niemand behauptet. Ja? Nick M. schrieb: > Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu > schreiben. > Unsigned long ist nämlich nicht genau definiert da plattformabhängig. > Es ist einfach schlechter Stil. Ihm stellt uint32_t in Vergleich zu unsigned long. Und benutzt als Kriterium die Plattformabhängigkeit. Woraus ich geschlossen habe, dass ihm fest davon ausgeht, dass uint32_t eben viel besser ist, da Plattform unabhängig. Ein Umkehrschluss ist nicht unbedingt richtig..... ok .... Und dennoch erscheint es mir widersinnig, die Plattformabhängikeit dem unsigned long anzukreiden, und die Plattformabhängige Existenz des unit32_t auszublenden. Mit z.B. uint_least32_t (und seinen Brüdern) habe ich keine Probleme! Auch nicht in der Stilfrage. uint_least32_t (und Kumpels) sollten bei jedem halbwegs modernen Compiler verfügbar sein.
Hallo, Sebastian W. schrieb: > Sich der Lüge zu zeihen oder andere persönliche Anwürfe scheinen > inzwischen normal geworden zu sein. Wobei es sich bei den "Bezichtigern" fast immer um den gleichen, recht kleinen aber lautstarken Personenkreis handelt. > Mir fällt es zunehmend schwerer den ja fachlich interessanten Debatten > (so wie dieser) mit Interesse zu folgen. Du musst nur lernen derartige Anwürfe auszublenden, am besten durch nicht Beachtung des entsprechenden Personenkreises. Dann klappt es auch mit dem Erkenntnisgewinn trotz schwieriger Diskussionsumgebung. :-) rhf P.S. Lothar M. schrieb: > Und wenn es irgendein Compilerbauer in dem seither vergangenen viertel > Jahrhundert nicht geschafft hat, diese Funktionalität zu implementieren > (bzw. den nötigen Header mitzuliefern), dann gäbe mir das zu denken. Dem ist nichts hinzuzufügen.
Beitrag #6562386 wurde von einem Moderator gelöscht.
Rolf M. schrieb: > Eigentlich ging es nur um folgende Berechnung: > > Franz schrieb: >> a = 0x10000F23 >> a = (a << 3) > > Eine 29-Bit-CAN-ID soll um drei Bit nach links geschoben werden. Dass > das Ergebnis nachher in ein Register geschrieben wird, ist dafür > eigentlich gar nicht relevant. Doch. Denn wenn uint_least32t tatsächlich länger als 32 Bit sein sollte, würde es bei der Zuweisung zumindest eine Warnung geben. Deswegen würde ich tatsächlich uint_32t vorziehen. Den Fall, daß es das nicht gibt, können wir getrost als akademisch betrachten. Das Target ist AVR, da gibts das auf jeden Fall.
He Fanboy, alles gut, Deine Beiträge hier sind gut wichtig und regen zum Nachdenken an. Und wer, wie ich gerade, die Diskussion von oben bis unten komplett ließt, stellt auch fest, dass es bereits unsachlich wurde mit: Nick M. schrieb: > Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu > schreiben. Dieser "Vorschriftston" ist nunmal provokant. Nick M. schrieb: > Es ist einfach schlechter Stil. Und das ist auch nicht besser. So könnte man auch behaupten (und mehr als eine Behauptung ist es nunmal nicht), C sei schlechter Stil. Man kann in C plattformunabhängig programmieren, aber ureigentlich ist C als Hochsprache zum hardware-nahen Programmieren gedacht! Insofern sind die uralten Definitionen aus C89 noch immer und noch viele Jahrzehnte guter Stil und gültig: 16 Bit <= |short| <= |int| <= |long| >= 32 Bit Mit der Folge, dass short immer 16 Bit ist und long immer mindestens 32 Bit.
Elektry schrieb: > 16 Bit <= |short| <= |int| <= |long| >= 32 Bit 16 Bit = 32 Bit ist auch 'ne Logik. > Mit der Folge, dass short immer 16 Bit ist und long immer mindestens 32 > Bit.8 So war's vielleicht gewollt, so steht's aber nicht da.
MWS schrieb: > Elektry schrieb: >> 16 Bit <= |short| <= |int| <= |long| >= 32 Bit > > 16 Bit = 32 Bit ist auch 'ne Logik. > >> Mit der Folge, dass short immer 16 Bit ist und long immer mindestens 32 >> Bit.8 > > So war's vielleicht gewollt, so steht's aber nicht da. DAS Problem hier ist das unerträgliche Schlaumeiertum! Mal für die einfachen Gemüter: Setze für die drei Variablen drei Zahlen ein, so dass die Ungleichung wahr wird! Ich gabe mal einen Tipp: 16 <= 16 <= 32 <= 64 >= 32, huch, das ist ja WAHR Oder: 16 <= 16 <= 16 <= 32 >= 3, huch, das auch...
Sebastian W. schrieb: > Sich der Lüge zu zeihen oder andere > persönliche Anwürfe scheinen inzwischen normal geworden zu sein. Arduino Fanboy D. schrieb: > Genau die Behauptung, dass unt32_t Plattform unabhängig ist, ist eine > Lüge. hmmm, ich frage mich wer sich gerade und wieder mal im Ton vergreift! Dem C-Compiler und Quelltextlesern nun mal klar und deutlich zu sagen welche Bitbreite man sich umgesetzt wünscht kann doch keine Lüge sein. Ob es Sinn hat oder Bytes spart ist Sache der Maschine, aber wer nur 16 Bit im Wertebreich braucht der muss nicht überall 32 oder mehr Bit vorsehen, mal wird es schlanker im Programm umgesetzt mal nicht, aber im Quelltext ist es verständlich unabhängig vom Prozessor.
Elektry schrieb: > Nick M. schrieb: >> Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu >> schreiben. > > Dieser "Vorschriftston" ist nunmal provokant. Was ist an "bitte" provokan? Hätte man noch ein "!" anhängen sollen? Warum hat sich der TO dann dafür bedankt, statt rumzupöbeln? Elektry schrieb: > Literatur? > K&R deutsch, 2nd ed., S.36 Kommentar dazu? Nick M. schrieb: > Nochdazu ist das mit unsigned char, long, ... dermaßen angestaubter C&R > Stil, dass ich nur mal dezent empfehlen kann aktuelle Programme > anzusehen. Nach bald 50 Jahren C kann man das schon mal verlangen. Ja, das sollte K&R heißen. :-) Ich hab meinen K&R vor über 20 Jahren weggeworfen. Warum? Verstaubtes Wissen, kein Wort von neueren C-Versionen. So sieht Fortbildung nicht aus, die jeder Arbeitgeber verlangt. Elektry schrieb: > Mit der Folge, dass short immer 16 Bit ist und long immer mindestens 32 > Bit. Gebetsmühle: Es geht um exakte Längen. Also Längen die immer gleich sind. Das heisst nicht mal länger oder mal kürzer. Und das auf jeder Plattform. Und wenn die Plattform die Länge nicht hat, dann ist sie ungeeignet, weil man ausdrücklich die Länge fordert.
Joachim B. schrieb: > Dem C-Compiler und Quelltextlesern nun mal klar und deutlich zu sagen > welche Bitbreite man sich umgesetzt wünscht kann doch keine Lüge sein. > Ob es Sinn hat oder Bytes spart ist Sache der Maschine, aber wer nur 16 > Bit im Wertebreich braucht der muss nicht überall 32 oder mehr Bit > vorsehen, mal wird es schlanker im Programm umgesetzt mal nicht, aber im > Quelltext ist es verständlich unabhängig vom Prozessor. unsigned long ist ein Datentype, welcher auf jeder Plattform zur Verfügung steht. Garantiert. Auch garantiert mindestens 32 Bit breit. Für uint32_t gibt es noch nicht mal die Garantie auf Existenz. Und jetzt sage du mir, welcher der beiden Typen ist weniger Plattformabhängig?
Arduino Fanboy D. schrieb: > Und jetzt sage du mir, welcher der beiden Typen ist weniger > Plattformabhängig? Beide! Der eine hat keine garantierte Länge, der andere existiert nicht garantiert. Es gibt keinen garantiert existierenden garantiert 32-bit grossen Integer-Datentyp in C99. Zumindest lese ich den Standard so. LG, Sebastian
Joachim B. schrieb: > hmmm, ich frage mich wer sich gerade und wieder mal im Ton vergreift! Und dafür gibt es natürlich zwei Minuspunkte. Die restliche, richtige und vernünftige (gefühlt) 100ste Erklärung eingeschlossen. Bei diesen Bewertungen können nur Zweifel an der fachlichen Kompetenz von mindestens 2 selbsternannten Schiedsrichtern aufkommen.
Arduino Fanboy D. schrieb: > unsigned long ist ein Datentype, welcher auf jeder Plattform zur > Verfügung steht. > Garantiert. > Auch garantiert mindestens 32 Bit breit. > > Für uint32_t gibt es noch nicht mal die Garantie auf Existenz. > > Und jetzt sage du mir, welcher der beiden Typen ist weniger > Plattformabhängig? Nach der Definition von 99% aller Programmierer im hier gegebenen Kontext von Bit-Schiebe-Operation, deren Ergebnis auf Hardware ausgegeben wird, bei dem es also auf eine exakte Länge ankommt: Der zweite. Denn wenn der nicht existiert, kompiliert das Programm nicht und es gibt eine Fehlermeldung. Im Gegensatz dazu bekommst du, wenn du unsigned long verwendest und davon ausgehst, es wird schon genau 32 Bit haben, wahrscheinlich hässliche Laufzeitfehler der Klasse "Ariane 5 Erstflug" - zum Glück meist nicht so teuer. MfG, Arno
Arduino Fanboy D. schrieb: > uint32_t wird implementiert, wenn der Prozessor/Compiler das von Hause > aus kann. > Sonst nicht. Was sollte ein µC mit einem 32-Bit-CAN-Register, wenn er es von zu Hause nicht kann? Bleib einfach bei der Aufgabenstellung: Es ist ein 32-Bit-Register anzusprechen. Dafür ist uint32_t der richtige Datentyp. Ich wette mit Dir, dass Du keinen µC finden wirst, der 32-Bit-Register hat, aber für den kein uint32_t implementiert ist. Dann wäre der C-Compiler für diesen µC schlicht unbrauchbar.
:
Bearbeitet durch Moderator
Arno schrieb: > Der zweite. Denn wenn der nicht existiert, kompiliert das Programm nicht > und es gibt eine Fehlermeldung. Das nennt man dann Plattform Unabhängigkeit! Oder ist es gar eine Abhängigkeit? Alternativ, könnte man auch einen anderen Prozessor, oder Toolchain, verwenden. Hat aber auch, so wie ich das sehe, nichts mit Plattform Unabhängigkeit zu tun. Arno schrieb: > Im Gegensatz dazu bekommst du, wenn du unsigned long verwendest und > davon ausgehst, es wird schon genau 32 Bit haben, wahrscheinlich > hässliche Laufzeitfehler .. Das lässt sich abhandeln.... > unsigned long verwendest und > davon ausgehst, es wird schon genau 32 Bit haben Wer davon ausgeht, sollte sich evtl. ein anderes Buch anschaffen.
Hallo, Elektry schrieb: > Mit der Folge, dass short immer 16 Bit ist... und Elektry schrieb: > Literatur? > > K&R deutsch, 2nd ed., S.36 Quelle: Programmieren in C, Zweite Ausgabe ANSI C, Kapitel 2.2 Datentypen und Speicherbedarf, Seite 36 Zitat: ---------- "Mit short und long sollen verschieden lange ganzzahlige Werte zur Verfügung stehen, soweit dies praktikabel ist; int wird normalerweise die "natürliche" Größe für eine Maschine sein. short belegt oft 16 Bits, long 32 Bits und int entweder 16 oder 32 Bits. Es steht jedem Übersetzer frei, sinnvolle Größen für seine Maschine zu wählen, nur mit den Einschränkungen, daß short und int wenigstens 16 Bits haben, long mindestens 32 Bits, und daß short nicht länger als int und int nicht länger als long sein darf." ---------- Zitat Ende Da steht nichts von " short sind immer 16 Bits". rhf
Nick M. schrieb: > Elektry schrieb: >> Nick M. schrieb: >>> Dann gewöhn dir bitte gleich an statt 'unsigned long' uint32_t zu >>> schreiben. >> Dieser "Vorschriftston" ist nunmal provokant. > Was ist an "bitte" provokan? Hätte man noch ein "!" anhängen sollen? Du hättest auch so was schreiben können: >>>> Als Tipp: nimm statt des 'unsigned long' einen uint32_t. Weniger Worte, weniger "unterschwellig agressiv". Arduino Fanboy D. schrieb: > Also mein Buch sagt: >> provided only if the implementation directly supports the type Korrekt: https://en.cppreference.com/w/cpp/types/integer > Es gibt also keine Pflicht das zu implementieren. Lass mal das "only" aus dem Text weg. Dann steht da: wenn die Hardware die Datenbreite unterstützt und bearbeiten kann, dann gibt es den entsprechenden Datentyp auch. Natürlich gibt es bei einem Prozessor, der z.B. keine einzelnen Bytes bearbeiten kann, dann auch keine uint8_t und keinen int8_t. Und das ist allemal besser, als wenn der Compiler aus den (unsigned) char dann eigenhändig 16 Bit nimmt und das hinterher garantiert irgendwo zur Laufzeit knirscht. Arno schrieb: > Denn wenn der nicht existiert, kompiliert das Programm nicht und es gibt > eine Fehlermeldung. Das wäre mir auch lieber, als wenn der Compiler in diesem Fall nach Gutdünken "das Beste draus macht".
:
Bearbeitet durch Moderator
Ein long kann, abhängig von der Plattform eine unterschiedliche Länge und damit Wertebereich haben. Das nennt man dann plattformabhängig. Ein long auf einer 64 Bit-CPU hat mehr Bits als auf einer 8 Bit CPU. Code, der sich implizit auf die Länge auf der 64 Bit-CPU verlässt wird auf 8 Bit nicht funktionieren. Also Plattformabhängig sein. Eine Library für Verschlüsselung muss die exakten Längen der Typen wissen und auch ausdrücklich angeben um Plattformunabhängig zu sein. Man könnte natürlich abhängig von der Plattform und dem Compiler und einiger geschickter #defines die bereits existierenden typen aus stdint nachbauen. Das müsste man dann für jede existierende Kombination von Plattform und Compiler machen. Man ist also Plattformabhängig.
Frank M. schrieb: > Bleib einfach bei der Aufgabenstellung: Es ist ein 32-Bit-Register > anzusprechen. Dafür ist uint32_t der richtige Datentyp. Und unsigned long ist genauso richtig. Zudem ist äußerst unwahrscheinlich, dass in den nächsten Jahrzehnten auf einem 8-Bit AVR C mit 64-Bit-Möglichkeit zur Verfügung gestellt wird. Wir sind hier bei hardware-naher Programmierung. Bevor ein 20 Jahre altes AVR Programm portiert wird, programmiert man es neu.
Frank M. schrieb: > Bleib einfach bei der Aufgabenstellung: Es ist ein 32-Bit-Register > anzusprechen. Dafür ist uint32_t der richtige Datentyp. Sage ich doch! Auf dem kleinen AVR-Gcc Teller ist das alles ok. Aber dann bitte nicht von "Plattform Unabhängig" sprechen. Denn das ist es nicht. Merke: Der Streit dreht sich nicht um: "Was ist das Beste im AVR Umfeld?" Frank M. schrieb: > Ich wette mit Dir, dass Du keinen µC finden wirst, der 32-Bit-Register > hat, aber für den kein uint32_t implementiert ist. Dann wäre der > C-Compiler für diesen µC schlicht unbrauchbar. Naja..... [c] unsigned long test = 4711; PORTB = test; [c] Ich schätze mal, dass auch dein Compiler das ohne Murren durch lässt. Ohne Laufzeitfehler. Klar, es verfallen ein paar Bit, aber das tut doch keinem weh. -- ja, ich weiß, der Vergleich hinkt etwas --
Elektry schrieb: > Insofern sind die uralten Definitionen aus C89 noch immer und noch viele > Jahrzehnte guter Stil und gültig: > > 16 Bit <= |short| <= |int| <= |long| >= 32 Bit > > Mit der Folge, dass short immer 16 Bit ist und long immer mindestens 32 > Bit. Hier steht nicht: Roland F. schrieb: > " short sind immer 16 Bits" Hier steht, dass die Folge der Definition von K&R war, dass nachfolgend entwickelte Compiler immer 16 Bit für short verwendeten.
Lothar M. schrieb: > Weniger Worte, weniger "unterschwellig agressiv". Und dann beklagst du dich, dass das ein Kindergarten ist, forderst aber, jeden wie ein Kind anzufassen? Soll ich ein laktosefreies veganisches Eis an meine Postings pappen damit auch jeder sich inkludiert fühlt? Soll ich alle Geschlechter durchdeklinieren? Soll ich eine türkische Übersetzung mitliefern? Soll ich Sonntags nicht mehr schreiben weil das Leute von der Sonntagsru ... oh Mist! Was ist mit Freitag? Soll ich so lange schwammig formulieren, bis jeder alles reininterpretieren kann, auch das Gegenteil? Sind schon wieder zu viele Personalpronomen dabei. Arme Welt.
D.h. es gibt durchaus alte Programme, bei denen das nicht so ist. Es gab ja auch damals "verbreitete" CPUs mit 18 Bit u.s.w.
Nick, kannst Du nicht einfach Deine Beiträge am Anfang als off-topic markieren, dann liesst man sie nicht aus Versehen? Das ist wirklich als höfliche Bitte gemeint, damit man Dich nicht blacklisten muss, denn Du trägst ja inhaltlich auch Interessantes bei
Der ganze Streit, was nun plattformabhängig ist und was nicht, resultiert meiner Ansicht nach daraus, dass hier tatsächlich zwei verschiedene Definitionen davon zugrunde liegen. Und die habe ich auch in der Vergangenheit schon öfters gesehen. Das einie ist die, die den Ideen hinter C zugrunde liegt, die andere ist die, wie sie es sie soweit ich weiß in Java gibt. Ich benenne die mal entsprechend, ohne dass das wertend sein soll, einfach um ihnen einen Namen zu geben. Die C-Variante sieht es eher aus Sicht des Compilers bzw. der Zielplattform. Bestimmte Eigenschaften der Datentypen werden nicht vom Standard festgezurrt, sondern dem Compiler überlassen. Dadurch lässt sich die Sprache auf allen Plattformen sinnvoll und effizient umsetzen. Dafür hat der Programmierer bestimmte Garantien nicht. Plattformunabhängig ist das in dem Sinne, dass es eben auf allen Plattformen eine sinnvolle Implementation gibt. Man kann damit natürlich auch Software schreiben, die sich auf den Plattformen gleich verhält, wenn man die Typen mit bedacht wählt. Die Java-Variante sieht das Ganze eher aus Sicht des Programmierers. int ist 32 Bit breit, garantiert und immer. Darauf kann ich mich verlassen. Allerdings bedeutet das auch, dass die Implementation dann auf bestimmen Architekturen suboptimal ist, und auf manchen sogar enteder gar nicht oder nur mit sehr umständlicher und ineffizienter Emulation umgesetzt ist. unsigned long kann man nun als plattforumunabhängig im C-Sinne bezeichnen, uint32_t im Java-Sinne. Es hat beides seine Vor- und Nachteile.
Kurzgeschichte: Der kleine AVR und der große PC unterhalten sich miteinander per RS232. Der AVR schickt ihm ein long.
Lothar M. schrieb: > Natürlich gibt es bei einem Prozessor, der z.B. keine einzelnen Bytes > bearbeiten kann, Hier muss ich Einspruch erheben. Du gehst davon aus, dass ein Byte 8 Bit hat. Die Annahme funktioniert in der Regel und auch in der Fantasie. Aber mit der C oder C++ Definition hat das wenig zu tun. Die spricht von dem "kleinsten zu verarbeitenden Datenobjekt". Und das ist eben char. Welches keineswegs auf 8Bit fixiert ist.
Nick M. schrieb: > Das ist dieser Mist mit dem int und long und ... > Ein int ist 2 Bytes oder 4 Bytes lang. Üblicherweise. Nicht auf meinem PC. Deswegen war das schon eine gute Idee, die stdint.h einzuführen. Wenn damit irgendwer ein Problem hat, dann geht mir das am Hintern vorbei. Zur Not kann er sich so eine Header Datei ja selbst erstellen.
Rolf M. schrieb: > plattformabhängig Das Problem ist, dass viele "Programmierer" nicht genug Erfahrung haben, um wissen zu können, dass der Begriff in jeglicher Lesart immer eine Utopie war, ist und bleiben wird. (Um diese Wahrheit zu erklären, bräuchte ich den Umfang eines Buches, aber langjährige Programmierer, die oft im Laufe von 30 Jahren z.B. alle 5 Jahre jeweils 10 Jahre alten Code warten mussten, werden mir zustimmen: Der Programmierstil und die Richtlinien, Normen und Weiterentwicklungen ändern sich so gravieren, dass es jedes Mal ein Riesen-Aufwand ist. Bestes Beispiel, wer seit 10 Jahrem für Android oder iOS Apps entwickelt, weiss, dass keine App aus der Anfangs- oder Mittelzeit jetzt noch reibungslos lauffähig ist, da ist der Begriff "plattformabhängig" völlig absurd, da es ja nicht mal von einer Handvoll Betriebssystem-Versionen unabhängig ist. Wer schonmal eine App von iOS nach Android portieren musste, wird sich über die hohen Ansprücke der "plattformunabhängigkeit" totlachen) Also, vergiss das "plattformabhängig" und schreib wenigstens so, dass es auf dieser Plattform in 20 Jahren noch einigermaßen zu warten sein wird. Das wäre schon etwas!
Nick M. schrieb: > Ein long auf einer 64 Bit-CPU hat mehr Bits als auf einer 8 Bit CPU. > Code, der sich implizit auf die Länge auf der 64 Bit-CPU verlässt wird > auf 8 Bit nicht funktionieren. Also Plattformabhängig sein. Wenn man sich auf etwas verlässt, das nicht garantiert ist, hat man einen Fehler gemacht. Man kann mit long durchaus Code schreiben, der sich auf allen Plattformen gleich verhält. Mit uint32_t geht das nicht, weil das nicht auf allen Plattformen existiert. Arduino Fanboy D. schrieb: > Lothar M. schrieb: >> Natürlich gibt es bei einem Prozessor, der z.B. keine einzelnen Bytes >> bearbeiten kann, > Hier muss ich Einspruch erheben. > > Du gehst davon aus, dass ein Byte 8 Bit hat. > Die Annahme funktioniert in der Regel und auch in der Fantasie. > Aber mit der C oder C++ Definition hat das wenig zu tun. > > Die spricht von dem "kleinsten zu verarbeitenden Datenobjekt". > Und das ist eben char. Welches keineswegs auf 8Bit fixiert ist. Ein char ist immer 1 Byte groß (sizeof(char) == 1). Ein Byte ist aber nicht unbedingt 8 Bit groß. In C ist nur definiert, dass es mindestens 8 Bit breit ist. Auf einem DSP, der nativ 24 Bit hat und in nichts kleinerem rechnen kann, könnten z.B. char, short und int 24 Bit breit sein, long 48 Bit und long long 72 Bit. Da gibt's dann auch kein uint8_t, uint16_t, uint32_t oder uint64_t. Das wäre aber auch völlig Standard-konform. Ein 32-Bit-Typ wäre auf so einem System kaum sinnvoll umsetzbar.
Elektry schrieb: > Nick, kannst Du nicht einfach Deine Beiträge am Anfang als off-topic > markieren, dann liesst man sie nicht aus Versehen? Sehr gute Idee! Dann überlegt euch doch alle mal wer was als OT empfindet und wie hoch der Mindestanteil an Buchstaben in dem Teil sein muss, der je zu berücksichtigenden Individuum von genau jener Person als OT bewertet wird. Bitte unter Berücksichtigung für die Gewichtung des OT-Inhalts. Jedes posting von mir wird dann individuell von mir mit einer Liste personenbezugener OT-Indizes versehen. Bei neu zustoßenden Teilnehmern, egal ob nur zum stänkern oder sachlich, werden ältere Postings selbstverständlich nachtäglich um den jeweiligen Index erweitert. Elektry schrieb: > Das ist wirklich als höfliche Bitte gemeint, damit man Dich nicht > blacklisten muss, denn Du trägst ja inhaltlich auch Interessantes bei Auch ich finde, dass wir alle für dich für ein neues C-Buch zusammenlegen sollten. Ich meine das auch höflich und ernst.
Rolf M. schrieb: > Mit uint32_t geht das nicht, > weil das nicht auf allen Plattformen existiert. Kannst du das konkretisieren? Welcher C Compiler unterstützt auf welcher Plattform den uint32_t nicht?
Stefan ⛄ F. schrieb: > Kannst du das konkretisieren? Welcher C Compiler unterstützt auf welcher > Plattform den uint32_t nicht? Wurde schon mehrfach genannt: DSP
Nick M. schrieb: > Wurde schon mehrfach genannt: DSP Wenn ich einen DSP Programmiere, der nur 24bit kann, dann wird mein Programm auch dementsprechend aussehen. Das ist ein Spezialfall, der ohnehin speziell programmiert wird. Ich versuche schließlich auch nicht mit meinem Hausahlts-Staubsauger eine Bäckerei zu reinigen.
Stefan ⛄ F. schrieb: > Ich versuche schließlich auch nicht mit meinem Hausahlts-Staubsauger > eine Bäckerei zu reinigen. Ich saug meine Wohnung mit einem Industriesauger. Das geht. Was hat das jetzt mit deiner Frage zu tun?
Stefan ⛄ F. schrieb: > Wenn ich einen DSP Programmiere, der nur 24bit kann, dann wird mein > Programm auch dementsprechend aussehen. Das ist ein Spezialfall, der > ohnehin speziell programmiert wird. Wenn unsigned long verwendet wird, hat man einen Datentype, welcher min. 32 Bit verarbeiten kann. Auf jedem C/C++ Kesselchen dieser Welt. Das nenne ich Plattformübergreifend. Wenn man uint32_t verwendet, hauts einem das manchmal um die Ohren. Das nenne ich, von der Plattform abhängig sein. Tipp: Mit Staubsaugern hat das nichts zu tun.
Beitrag #6562722 wurde von einem Moderator gelöscht.
Beitrag #6562732 wurde von einem Moderator gelöscht.
Es ist eine Sauerei, daß man nach 3 mal nach links schieben eine höhere Zahl bekommt. Jeder weiß, daß man nach 3 mal links gehen um einen Block wieder an der Ausgangsposition ankommt. Also müßte das Null ergeben. Ich finde es schlimm, wie der TO hier verwirrt wird. Zudem muß ich bemängeln, daß die Diskussion mit den Personalpronomen nicht zu Ende geführt wurde. Prinzipiell war es eine kleine Teilmenge der gewaltfreien Kommunikation, die hier zur Sprache kam. Es ist nunmal ein Unterschied, ob man sagt: "Ich finde, euch sollte man alle verdreschen", oder nur "Euch sollte man alle verdreschen". Das Voransetzen eines "Ich finde/meine/denke" entschärft aggressive Allgemeinplätze, erhebt keinen Anspruch auf Allgemeingültigkeit und den Rest könnt ihr in der Wiki nachlesen.
Beitrag #6562743 wurde von einem Moderator gelöscht.
Beitrag #6562755 wurde von einem Moderator gelöscht.
Beitrag #6562760 wurde von einem Moderator gelöscht.
Was lobe ich mir das Freepascal/Lazarus /Delphi. Auffällig ist, das es solche Grundsatzdiskussionen ständig in C Foren gibt
Beitrag #6562787 wurde von einem Moderator gelöscht.
Beitrag #6562792 wurde von einem Moderator gelöscht.
Beitrag #6562794 wurde von einem Moderator gelöscht.
Jürgen S. schrieb: > Es ist eine Sauerei, daß man nach 3 mal nach links schieben eine höhere > Zahl bekommt. Jeder weiß, daß man nach 3 mal links gehen um einen Block > wieder an der Ausgangsposition ankommt. Also müßte das Null ergeben. Ich > finde es schlimm, wie der TO hier verwirrt wird. kannst du das nochmal neu formulieren, so dass man ohne Verwirrung verstehen kann, was du meinst?
> Auffällig ist, das es solche Grundsatzdiskussionen > ständig in C Foren gibt Das stimmt. Dafür diskutieren die Java Entwickler gerne über Quelltext-Formatierung und welches Framework die Welt regieren soll.
Beitrag #6562820 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > kannst du das nochmal neu formulieren, so dass man ohne Verwirrung > verstehen kann, was du meinst? Nimm's am besten nicht allzu ernst, auch wenn es noch so schlimm ist :-)
Das Tolle ist doch, dass die Anfangsfrage schon nach wenigen Antworten vollständig beantwortet worden ist. Hat man auch nicht so oft. Viel häufiger beginnt das hier so früh, dass es nicht mehr zu einer brauchbaren Antwort kommt. Ein C Buch schreiben? Ich weiß, dass ich nichts weiss.
Elektry schrieb: > Das Tolle ist doch, dass die Anfangsfrage schon nach wenigen Antworten > vollständig beantwortet worden ist. Hat man auch nicht so oft. Eben. Und danach ging es wieder darum, wer mit dem Längsten am besten kann. Nur noch Schweinkram.
Elektry schrieb: > MWS schrieb: >> Elektry schrieb: >>> 16 Bit <= |short| <= |int| <= |long| >= 32 Bit > DAS Problem hier ist das unerträgliche Schlaumeiertum! > Mal für die einfachen Gemüter: Also schrubst Du jetzt diese Antwort nur für Dich selbst? > Setze für die drei Variablen drei Zahlen ein, so dass die Ungleichung > wahr wird! Wir reden hier über den Wertebereich von Datetypen. > 16 <= 16 <= 32 <= 64 >= 32, huch, das ist ja WAHR > Oder: > 16 <= 16 <= 16 <= 32 >= 3, huch, das auch... Da Du Schlaumeier alle Typen auch mit "=" verknüpft hast, ist die Aussage Deiner "Formel", dass der Wertebereich aller Typen auch gleich kann, was natürlich grandioser Unsinn ist. Verstehst Du das jetzt, oder soll ich langsamer für Dich schreiben?
MWS schrieb: > Da Du Schlaumeier alle Typen auch mit "=" verknüpft hast, ist die > Aussage Deiner "Formel", dass der Wertebereich aller Typen auch gleich > kann, was natürlich grandioser Unsinn ist. Du erstaunst mich... Ich rate dir zu einem guten Buch. Natürlich dürfen alle fundamentalen integer Typen gleich viel Bit breit sein. Ob das in der Praxis auch so ist, ist eine andere Frage. Aber sie dürfen. Der Wertebereich unterscheidet sich natürlich zwischen signed und unsigned. Da spielt auch noch mit rein, ob Einerkomplement oder Zweierkomplement .
Arduino Fanboy D. schrieb: > Wenn man uint32_t verwendet, hauts einem das manchmal um die Ohren. > Das nenne ich, von der Plattform abhängig sein. Du kannst auch die Farbe des Mittagshimmels grün nennen, aber wundere dich nicht, wenn man dich dann nicht mehr versteht. MfG, Arno
Arduino Fanboy D. schrieb: > Ich rate dir zu einem guten Buch. Und ich rate dazu, dass Du nur darauf antwortest, was Du inhaltlich verstanden hast. > Natürlich dürfen alle fundamentalen integer Typen gleich breit sein. Das war nicht das Thema.
MWS schrieb: >> Natürlich dürfen alle fundamentalen integer Typen gleich breit sein. > > Das war nicht das Thema. Ja? Elektry (Gast) sprach nur über die Breiten! Oder?
Beitrag #6562915 wurde von einem Moderator gelöscht.
Beitrag #6562948 wurde von einem Moderator gelöscht.
Beitrag #6563030 wurde von einem Moderator gelöscht.
Beitrag #6563035 wurde von einem Moderator gelöscht.
Beitrag #6563049 wurde von einem Moderator gelöscht.
Beitrag #6563055 wurde von einem Moderator gelöscht.
Beitrag #6563066 wurde von einem Moderator gelöscht.
Beitrag #6563068 wurde von einem Moderator gelöscht.
Beitrag #6563069 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten