Datentypen in C

Dominik M. schrieb:
> Ich konnte leider nichts im Forum über "Datentypen in C" finden.

Es gibt auch C-Bücher...

char ist die kleinste auf dem jeweiligen Rechner adressierbare Größe,
int die natürliche Größe des jeweiligen Prozessors.
short und long entsprechend.

char selbst kann signed oder unsigned sein, das kann der 
Compilerhersteller machen wie er will.
Wenn man es genauer haben will, schreibt man signed oder unsigned davor.

STK500-Besitzer schrieb:
> Was könnte wohl "unsigned" heissen?

naja, wenn ein char zufällig bspw. 8 Bit hat und das oberste davon das 
Vorzeichen angibt, könnte unsigned auch heißen, daß es dann nur noch 7 
Bit hat :-)

Dominik M. schrieb:
> Ich konnte leider nichts im Forum über "Datentypen in C" finden.

Zwar nicht im Forum, aber nur drei Klicks entfernt:

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Ganzzahlige_.28Integer.29_Datentypen

http://openbook.galileocomputing.de/c_von_a_bis_z/005_c_basisdatentypen_001.htm#mjeda2957449ddc812dad62b400fe57752

Das ist kostenlos. Einfach durch kapitel 5 weiter durchhangeln.
Und Tschüss.

Ratgeber schrieb:
> Unsigned heißt "nicht gezeichnet" und bedeutet daß die Variable
> gedruckt werden kann (kommt noch aus den Zeiten wo es Plotter gab)

und Motherboards heißen Mutterbretter. Das kommt noch aus den Zeiten als 
Mutti den Computer zusammen gebaut hat.

"sign" ist einfach das Vorzeichen, also vorzeichenlos bzw 
vorzeichen-behaftet. Will man den Wertebereich einer Zahl erweitern, muß 
man halt irgendwie ein bit opfern (daß das Vorzeichen enthält) und kommt 
dann auf ca. -128 .. +127 anstatt (+)0 .. (+)255

ps: sowas kann man auch in der Wiki nachlesen
http://de.wikipedia.org/wiki/Integer_%28Datentyp%29#Maximaler_Wertebereich_von_Integer

http://www.google.de/search?q=Datentypen+in+C&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Dosmo schrieb:
> Es ist eine ziemliche Heimtücke von C, daß die Bitbreite der Datentypen
> vom Prozessor (genauer gesagt: vom C-Compiler für diesen Prozessor)
> abhängen.

Das ist allgemein Bekannt und in jedem C-Für-Controller-Buch, Wiki und 
sonstwas immer bei den ersten Schritten erklärt.
Wäre das etwas schwarze Magie, würde man hier viel öfter Probleme darauf 
zurückführen können.

Dosmo schrieb:

> Auf einem 32-Bit-Controller ist das "int" natürlich 32-Bit breit.

Und auf einem 64-Bit-Prozessor ist das "int" natürlich wie breit? ;-)

In Linux auch. War aber schlecht vermeidbar, weil man sonst einen 
zusätzlichen Datentyp für 32 Bits hätte definieren müssen.

Noch besser wird es bei "long", da sich die beiden wichtigsten 64-Bit 
Welten Windows und Linux darüber nicht einig sind, also ob das 64 Bits 
sind (Linux, LP64) oder 32 (Windows, LLP64). Weil Microsoft höchstselbst 
über die Interpretation und Kopplung von Typ und Grösse in Windows 
stolperte und den Anwendern das natürliche "long" für 64 Bits nicht 
zumuten wollte.

bernie schrieb:
> Der Sprachkonstrukt ist unverständlich und unglaublich fehleranfällig,
> verschiedene Kompiler erzeugen selbst aus trivialen Quelltexten
> Kompilate mit unterschiedlichen Ergebnissen,

Was im Reglfall praktisch immer auf fehlende Kentnisse beim 
Programmierer zurückzuführen ist.

> ständig benötigte
> Formatierungssymbole lassen sich auf deutschen Tastaturen nur per
> Fingerakrobatik erreichen,

dann nimm halt eine englische Tastatur. Da sind alle Sonderzeichen gut 
zu erreichen

> hinsichtlich der Datentypen und Boundarywraps
> bei Arrays auf Mikrocontrollern herrscht babylonische Verwirrung.

eigentlich tut es das .... nicht

> Warum
> eigentlich gibt es noch immer weltfremde, welche ernsthaft versuchen,
> mit dieser möchtegern-Programmiersprache "Software" zu erzeugen?

Weil diese 'Möchtegern-Programmierer' mit diese Sprache bisher eine 
Unmenge von ganz ordentlicher Software geschrieben haben?

>> redlich zu leben, Lebensfreude zu erkennen und schwört dem Schwachsinn
> und der Verblendung ab! (und lernt JAVA,

hahahahahaha.
Danke. You made my day.

bernie schrieb:
>> hahahahahaha.
>> Danke. You made my day.
>
> Überzeugter C-Fan, vermute ich?

Auch.
Aber seit vielen Jahren ist es C++.

(womit wir dann auch bei Klassen wären)

bernie schrieb:
> Der Sprachkonstrukt ist unverständlich und unglaublich fehleranfällig...

Was meine alte Theorie bestätigt: Leute, die natürlichen Text nicht 
formulieren können und eine Rechtschreibschwäche haben, können auch 
nicht programmieren.
Je schlimmer die Formulierungen, umso größer die Probleme beim 
Programmieren.
Das Forum hier ist voll von Beispielen dafür.

(Aber für die gibt es ja VB und Konsorten, also alles kein Problem.)

Klaus Wachtler schrieb:

> Was meine alte Theorie bestätigt: Leute, die natürlichen Text nicht
> formulieren können und eine Rechtschreibschwäche haben, können auch
> nicht programmieren.

Wobei man aber auch bei eher unterentwickelter Rechtschreibschwäche 
trotzdem C und insbesondere C++ nicht unbedingt mögen muss. C mag in den 
70ern und 80ern leidlich adäquat gewesen sein, weil man mit geringem 
Aufwand Compiler für alle Plattformen stemmen konnte. Und wesentlich 
damit, sowie mit Unix, hängt auch der heutige Erfolg von C zusammen. 
Nicht jedoch mit seiner Qualität als Programmiersprache.

An sich ist C aus heutiger Sicht eine ziemliche Zumutung und C++ ist 
m.E. eher schlimmer, weil es vorgibt, eine highlevel Sprache zu sein, 
aber all den dabei hinderlichen lowlevel Kram von C mitschleppt. Von der 
syntaktischen Seite ganz abgesehen - da hatte mir C++ bereits beim 
ersten Kontakt wenig Freude bereitet. Und ich meine damit nicht die 
Sonderzeichenverwendung - meine erste Programmiererfahrung fand 
schliesslich in APL statt ;-).

Aber diese Sprachen sind nun einmal da, sie sind verwendbar und ich 
kenne mich in beiden ganz passabel aus. Ist ein bisschen wie Deutsch, 
das ist auch nicht die beste Sprache unter der Sonne, aber ich kann es 
nun einmal besser und die Verständigung mit der Umgebung klappt auch 
besser.

bernie schrieb:
> Versucht nach vorne zu sehen,
> redlich zu leben, Lebensfreude zu erkennen und schwört dem Schwachsinn
> und der Verblendung ab! (und lernt JAVA, denn da gibts für das, was Ihr
> in mehrjähriger mühevoller fronarbeit zusammengebastelt habt und als
> vollfunktionsumfänglichesoftwarelösungfürdenmittelstand bezeichnet, eine
> fertige Klasse!)
>
> ;-)

Um noch mehr Fehler und Kosten dank Java zu erzeugen...
http://www.heise.de/newsticker/meldung/Unterhalt-von-Java-Software-teurer-als-von-Cobol-Programmen-1392849.html

bernie schrieb:

> Hm, interessanter Ansatz. Meiner Ansicht nach leider ich weder unter
> einer Rechtschreibschwäche, noch kann ich bei nochmaligen durchlesen
> meines Postings eklatante Rechtschreibfehler entdecken. Aber Du zielst
> sicher auf etwas anderes ab und empfindest z.B. sowas hier:

Vielleicht eher darauf, dass ein Konstrukt ein Neutrum ist, und daher
"Der Sprachkonstrukt ist unverständlich" auch in schönster 
Selbstbezüglichkeit zutrifft ;-). Aber das ist Korinthenkackerei, wenn 
ernst gemeint.

Aber ich halte wenig von seiner These, denn ich kann in meinem 
Bekanntenkreis keine Korrelation zwischen Rechtschreibung und Fähigkeit 
zum Programmieren erkennen. Eine gewisse Legasthenie muss dabei auch 
kein Hindernis darstellen. Wogegen gute Rechtschreibung und völlige 
Unfähigkeit zur Programmierung durchaus zusammen zu passen scheinen.

bernie schrieb:
> Klaus Wachtel schrieb:

Es gibt bei der Volkshochschule vielleicht einen Einsteigerkurs für 
"copy & paste" oder "Zitieren für Anfänger"?

>
>> Was meine alte Theorie bestätigt: Leute, die natürlichen Text nicht
>> formulieren können und eine Rechtschreibschwäche haben, können auch
>> nicht programmieren.
>
> Hm, interessanter Ansatz. Meiner Ansicht nach leider ich weder unter
> einer Rechtschreibschwäche, noch kann ich bei nochmaligen durchlesen
> meines Postings eklatante Rechtschreibfehler entdecken.

Du schaffst es ja nicht mal, den Namen korrekt zu zitieren - vermutlich 
also nur Getrolle, der Rest deiner Äußerungen passt dazu.

Leider weiter....

> Aber Du zielst
> sicher auf etwas anderes ab und empfindest z.B. sowas hier:
>
> float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
> (h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
> %6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
>
> als "verständlichen, natürlichen" Text?

Nein, falsch geraten - oder schlecht getrollt.

Wenn deine C-Kenntnisse nicht über diese Art von Programm hinausreichen, 
macht es Sinn, bei etwas anderem zu bleiben.
Ob deine Java-Programme besser sind, kann ich nicht beurteilen.

Aber in letzter Zeit scheint es Mode zu sein, daß in jedem Thread 
irgendein selbsternannter Experte seine neue Erkenntnis loswird, daß C 
so schlecht und alles andere so toll, egal um welches Thema es geht und 
egal, ob es jemand hören will.
Vielleicht ist es ja auch nur immer derselbe Troll, der stänkern will.

Zur Erinnerung: es geht in diesem Forum um Mikrokontroller (was das ist, 
kann man z.B. auf Wikipedia schon mal ansatzweise in Erfahrung bringen). 
Da ist es sicher hilfreich und Quell unendlichen Dankes, die Leute von C 
oder dem noch schlimmeren Assembler zu heilen und zum 
Licht^H^H^H^H^HJava zu führen.

Alleine beim Anblick dieses guten Rats erschließt sich schnell deine 
umfassende Kenntnis von der Materie, Glückwunsch!

> Bestimmt kannst Du beim bloßen
> Anblick dieses "übersichtlichen" und "gut strukturierten" Quelltexte
> sofort sagen, was das Ergebnis dieses m.E. nach Murks ist,

Da hast du ausnahmsweise sogar Recht - das ist Murks.
Aber kann die Sprache etwas dafür?
Kann die deutsche Sprache etwas dafür, daß jemand so einen Mist darin 
erzählt?

Und in Java werden im Umkehrschluß nur gute Programme geschrieben? Und 
du bist ein toller Programmierer, weil du Hello World in Java gemeistert 
hast?

Logisches Denken scheint nicht deine Stärke zu sein.

> sofern
> irgendein Compiler sich gewogen fühlt, daraus soetwas ähnliches wie ein
> lauffähiges Programm zu erzeugen. Kann es sein, das es sich bei Dir um
> einen unverbesserlichen C-Fanboy

falsch.

> mit mangelhafter Sozialisierung

falsch.

> handelt, der sich gerade ganz kräftig auf den Schlips getreten fühlt,
> weil es jemand gewagt hat, "seine" Programmiersprache, den Mittelpunkt
> seines Daseins, das Einzige, was er seit 20 Jahren

länger, aber nicht nur C.

> so einigermaßen beherrscht,

hoffentlich besser als du.

> als Spielzeug für Sonderschulkinder bloßzustellen?

Wenn das deine Meinung ist, aber sie zeugt nicht von Fachkenntnis.

> Wenn es
> für Dich i.O. ist, Deinen trübseligen und belanglosen Alltag mit dem
> Schreiben von funktions- und ergebnislosen C-Quelltexten etwas
> aufzuheitern - Nur zu. So richtest Du wenigstens (hoffentlich!)
> anderweitig keinen Schaden an.

Den Gefallen werde ich dir nicht tun, ich mache auch anderweitig die 
Welt unsicher.

Wenn du dich vollkommen zum Horst machen willst, dann zeig doch mal, was 
für tolle Sachen du auf einem Controller in Java machst. Vielleicht 
kannst du ja jemanden wirklich beeindrucken.
Ich werde es wohlwollend begleiten...

Aber nimm es nicht so schwer, anonym kann man getrost den grössten 
Blödsinn erzählen. Morgen in der Schule weiß ja keiner, wer es war.

Klaus Wachtler schrieb:
> Wenn du dich vollkommen zum Horst machen willst, dann zeig doch mal, was
> für tolle Sachen du auf einem Controller in Java machst.

Daß er irgendwas mit Java macht, ist eher unwahrscheinlich, denn da 
bräuchte er auch genau die

> ständig benötigte[n] Formatierungssymbole[, die] (...) sich auf
> deutschen Tastaturen nur per Fingerakrobatik erreichen [lassen]

Und bei den

> Boundarywraps bei Arrays (...) herrscht [in Java die gleiche]
> babylonische Verwirrung [wie in C]

nämlich exakt keine.

Also wird der gudsde mit irgendeinem Pascal- oder Basic-Dialekt die Welt 
verbessern wollen.

oder einfach nur - trollen.

PS:

Nur mal am Rande - gibt es in Java überhaupt mehr als 32 Bit, wenn man 
es braucht?

Klaus Wachtler schrieb:

> Nur mal am Rande - gibt es in Java überhaupt mehr als 32 Bit, wenn man
> es braucht?

long

Dosmo schrieb:
> Es ist eine ziemliche Heimtücke von C, daß die Bitbreite der Datentypen
> vom Prozessor (genauer gesagt: vom C-Compiler für diesen Prozessor)
> abhängen.

Es ist "Implementaton Defined", hängt also einzig und allein vom 
verwendeten Compiler ab.

Es gibt keinen Bezug zwischen int, short, long, ... zur Hardware — 
zumandest was den Sprachstandard angeht.

Freilich wird die Implementierung i.d.R so gemacht, daß sie halbwegs 
effizient auf die Hardware abbildet.

Aber einem C-Compiler ist es nicht verboten, int für einen AVR als 64 
Bit zu implementieren oder auf einem Itanium-64 als 16 Bit.

Johann L. schrieb:
> Es gibt keinen Bezug zwischen int, short, long,

Naja, short ≤ int ≤ long gilt schon.

Klaus Wachtler schrieb:
> bernie schrieb:
>> Der Sprachkonstrukt ist unverständlich und unglaublich fehleranfällig...
>
> Was meine alte Theorie bestätigt: Leute, die natürlichen Text nicht
> formulieren können und eine Rechtschreibschwäche haben, können auch
> nicht programmieren.
> Je schlimmer die Formulierungen, umso größer die Probleme beim
> Programmieren.
> Das Forum hier ist voll von Beispielen dafür.
>
> (Aber für die gibt es ja VB und Konsorten, also alles kein Problem.)

Also so eine These oder Theorie halte ich gelinde gesagt für gewagt. 
Etwas direkter ausgedrückt, diese "These" ist der blanke Unsinn. In 
meiner Schulzeit waren Mädchen im Schnitt IMMER signifikant besser in 
Rechtschreibung gegenüber den Jungs. Nur waren sie dafür in Mathe so 
ziemlich alle Nieten und ich wage mal zu behaupten, dass die Mathe 
ungleich wichtiger im Sinne des strukturierten Denkens ist, als ein 
Diktat fehlerfrei oder mit wenigen Fehlern abliefern zu können.

Also gute Diktatschreiber sind mit Sicherheit nicht die herausragenden 
Programmierer, sonst wären Chef-Sekretärinnen schließlich die Clientel 
für den Softwaremarkt. ;-)

g. c. schrieb:
> Also so eine These oder Theorie halte ich gelinde gesagt für gewagt.
> Etwas direkter ausgedrückt, diese "These" ist der blanke Unsinn. In
> meiner Schulzeit waren Mädchen im Schnitt IMMER signifikant besser in
> Rechtschreibung gegenüber den Jungs.
>
> Nur waren sie dafür in Mathe so
> ziemlich alle Nieten und ich wage mal zu behaupten, dass die Mathe
> ungleich wichtiger im Sinne des strukturierten Denkens ist, als ein
> Diktat fehlerfrei oder mit wenigen Fehlern abliefern zu können.
>
> Also gute Diktatschreiber sind mit Sicherheit nicht die herausragenden
> Programmierer, sonst wären Chef-Sekretärinnen schließlich die Clientel
> für den Softwaremarkt. ;-)

Scheinbar gilt dies tatsächlich in DE ;-)
http://de.wikipedia.org/wiki/Intelligenz_als_Persönlichkeitseigenschaft
(das die Deutschnote am besten mit dem IQ korreliert, gilt nur hier in 
DE, erklärte Varianz 0.46^2 ~ 21%, dagegen in den USA
http://en.wikipedia.org/wiki/Intelligence_quotient#Other_tests
(Mathematik 0.76^2 ~ 58.6%)

Auf was die Unterschiede (zw. Jungen und Mädchen) zurückgeführt werden 
(können) u.a.
http://www.kellogg.northwestern.edu/faculty/sapienza/htm/science.pdf
http://www.faz.net/aktuell/politik/inland/oecd-studie-klischees-bestimmen-schulleistungen-von-jungen-und-maedchen-1796773.html

g. c. schrieb:

> meiner Schulzeit waren Mädchen im Schnitt IMMER signifikant besser in
> Rechtschreibung gegenüber den Jungs. Nur waren sie dafür in Mathe so
> ziemlich alle Nieten

Den Zusammenhang mit Mathe kann ich nicht feststellen. Für Physik traf 
das zu, aber nicht für Mathe, da waren die Mädels mit vorne dabei. In 
Qualität wie Interesse.

g. c. schrieb:
> Also so eine These oder Theorie halte ich gelinde gesagt für gewagt.
> Etwas direkter ausgedrückt, diese "These" ist der blanke Unsinn. In
> meiner Schulzeit waren Mädchen im Schnitt IMMER signifikant besser in
> Rechtschreibung gegenüber den Jungs. Nur waren sie dafür in Mathe so
> ziemlich alle Nieten und ich wage mal zu behaupten, dass die Mathe
> ungleich wichtiger im Sinne des strukturierten Denkens ist, als ein
> Diktat fehlerfrei oder mit wenigen Fehlern abliefern zu können.

Er hat nie behauptet, dass jeder der gut in Rechtschreibung und 
Grammatik ist, auch gut programmieren kann.
Er hat gesagt, dass jemand, der keine Rechtschreibung und Grammatik 
beherrscht, kein guter Pogrammierer sein kann.


¬A -> ¬B
heißt nicht automatisch
A -> B

Vlad Tepesch schrieb:
> Er hat nie behauptet, dass jeder der gut in Rechtschreibung und
> Grammatik ist, auch gut programmieren kann.
> Er hat gesagt, dass jemand, der keine Rechtschreibung und Grammatik
> beherrscht, kein guter Pogrammierer sein kann.

Auch dafür gibt es keinen Beweis. Was kann man schon aus 
hingeschlotterten Forentexten ableiten?! Hier im Forum sind die größten 
Helden unterwegs, die gerne an anderen herumnörgeln, aber selbst 
konsequent Groß- und Kleinschreibung missachten. Können die jetzt kein 
bisschen programmieren, bloß weil die "alles falsch" schreiben?

fortran-freund schrieb:
> Die beste Programmiersprache ist die, die jemand richtig beherrscht .

Im Prinzip ja, praktisch aber nicht.

Was nützt eine Programmiersprache, die jemand perfekt beherrscht, die 
aber für eine Aufgabe ungeeignet ist?

fortran-freund schrieb:
> Das müßte bei dem Umfang aktueller Programmiersprachen aber eine sehr
> spezielle Aufgabe sein .

Da es in diesem Forum auch um die Microcontrollerprogrammierung geht 
(wenn auch nicht in diesem Unterforum hier), ist diese spezielle Aufgabe 
sehr schnell erreicht - einen µC will wohl kaum wer in so etwas wie 
Fortran, Cobol, Lisp etc. programmieren, geschweige denn, daß es für 
derartige Versuche überhaupt Compiler geben dürfte.

Übrigens: Du plenkst.

Rufus Τ. Firefly schrieb:
> Da es in diesem Forum auch um die Microcontrollerprogrammierung geht
> (wenn auch nicht in diesem Unterforum hier), ist diese spezielle Aufgabe
> sehr schnell erreicht - einen µC will wohl kaum wer in so etwas wie
> Fortran, Cobol, Lisp etc. programmieren, geschweige denn, daß es für
> derartige Versuche überhaupt Compiler geben dürfte.

Sag das nicht zu laut...
http://armpit.sourceforge.net/
"Armpit Scheme, once loaded, governs the operation of the MCU, and is 
"Scheme to the metal" in the sense of running without any other OS. It 
may be thought of as turning the MCU into a rudimentary Scheme machine."

scnr

Wieso Hexcode? Binär, per Schalter und Leuchten:
http://computermuseum.informatik.uni-stuttgart.de/dev/pdp1120/