Ich bin ja nun nicht der C Guru, will aber doch auf ein paar deiner Punkte eingehen.

Zitat Zitat von Siro Beitrag anzeigen
Also ich glaube (also bin ich) man hat sich irgendwann mal auf den Blödsinn von K&R eingelassen.
daß dies eine Fehlentscheidung war, hat man erst viel zu spät bemerkt und nun muss das natürlich gerechtfertigt werden
Ich habe in meiner C "Lehrzeit" (schon ne Weile her) noch einen Menge mehr, als das klasische Buch von Kernighan, Ritchie und Co. gelesen. Unter anderem aus "The Elements of Programming Style" von Kernighan und Plauger habe ich viel gelernt.

Wie schon gesagt, es ist ja nicht alles schlecht in "C". Man hätte meiner Meinung nach frühzeitig einige Änderungen vollziehen müssen,
das wurde irgendwie versäumt und nun muss man sich halt mit den teilweisen merkwürdigen Gegebenheiten rumschlagen.
Lies mal mehr über die Syntax und Semantik von C (oder auch Programmiersprachen generell), dann wirst du erkennen, daß man manches nicht so einfach "machen" kann, ohne Mehrdeutigkeiten oder andere Probleme zu erzeugen. Eine Programmiersprache muß ähnlich gesehen werden, wie ein mathematisches System.

ich hasse zum Beispiel solche Aussagen:
Normalerweise, vermutlich, meistens. Abhängig von... Je nachdem...
Das kommt daher, daß der Auskunftgeber es halt nicht besser weiß. Frag jemand, der sich wirklich auskennt.

Hätte man nicht mal sagen können ein Byte hat generell 8 Bit ein Word hat 16 Bit, ein int hat immer ein Vorzeichen und hat 16 Bit
Ist ja fast so. Ein char hat immer 8 Bit. Signed oder unsigned spielt keine wirkliche Rolle, eigentlich wird damit nicht gerechnet. Was macht auch 'a' * '@` für einen Sinn? Und daß '0' gleich 0x30 ist, gilt auch nur für ASCII und nicht für EBCDIC. K&R-C funktioniert auch mit EBCDIC.

Und ein int hat 16 Bit (mindestens). Solage du im Zahlenraum von +- 32000 bleibst, spielt es doch keine Rolle, ob dein int in Wirklichkeit größer ist. Das mußt du nicht wissen.

Ein Bool (TRUE) ist alles was nicht 0 ist
Das ist so. Ich weiß nicht, wie du auf etwas anderes kommst.

if (irgenwas == etwas)
in Klammern setzen und warum muss die Abfrage "besonders" gleich sein, also doppelt ==
Wegen der Eindeutigkeit. Der Ausdruck hinter dem if kann ganz schön länglich werden und auch noch eine menge weitere Klammern enthalten.

Code:
if ( ( a == 3 || b = 5)  && open(file))
In jeder Sprache gibt es den Unterschied zwischen Zuweisung "=" und Vergleich "==". Es sind ja auch fundamental unterschiedliche Sachen. War da in Pascal nicht was mit ":="?

Oder eine einfache Abfrage
if (blabla)
Für den Compiler ist es egal, daß du die Abfrage einfach nennst.
Mathematisch völliger Blödsinn. Einen einzelnen Ausdruck in Klammern zu setzen.
Woran soll der Compiler, oder der Mensch, der den Code verstehen will erkennen, das der Ausdruck zuende ist, und die Anweisung, die er bei true ausführen soll anfängt?

x = ~y;

geht nur wenn x und y ein "int" sind, sonst werd ich angemeckert.
wenn beide ein unsigned short sind, hat der Compiler Probleme ????
Ich kann das jetzt nicht nachvollziehen. Bitweise Operationen haben aber immer so ihre Probleme. Währen für den Bitoperator das oberste Bit eins wie die anderen ist, bedeutet es für Zahlen das Vorzeichen.

Das wirkliche Problem ist, das es in den meissten Sprachen zuwenig Datentypen gibt. Bitweise Operationen machen auf Zahlen im mathematischen Kontext keinen Sinn. Was soll soetwas bedeuten

Code:
X = ((3 * 5)/17) | (5 + 13)
Dies läßt sich hier sicher ausrechnen, aber ..

So ein Statusregister in einem µc passt möglicherweise ganz gut in den Speicherplatz eines Integers, hat aber mit einem int eigentlich nichts zu tun. Und es kann ganz tricky sein, irgendein Bit mit einer mathematischen Operation zu setzen, aber eigentlich ist so was nicht C, sonder Assembler in Verkleidung.

So weit erstmal

MfG Klebwax