Verständnisproblem in AVR C Syntax

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

c-hater schrieb:
> also 0x80007918

nee! aber besser 0x8007918

kannAllesBesser! schrieb:
> nee! aber besser 0x8007918

nehme alles zurück! war eine null zu wenig

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.

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.

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

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.

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.

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.

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:
> 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

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.

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!

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.

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.

Literatur?

K&R deutsch, 2nd ed., S.36

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

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?

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

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.

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

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!

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.

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.

Was lobe ich mir das Freepascal/Lazarus /Delphi.

Auffällig ist, das es solche Grundsatzdiskussionen ständig in C Foren 
gibt

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.

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?