Ohne "C" bräuchten wir keine Debugger

[Klebwax]

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

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.

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

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

[Calis007]

"Also ich glaube (also bin ich) man hat sich irgendwann mal auf den Blödsinn von K&R eingelassen."

Naja, 'irgendwann' war zu einer Zeit, als es nichts besseres gab. In C konnte man schon den Unix-Kernel effizient programmieren, als Pascal noch eine umstaendliche, langsame Lehrsprache war - indiskutabel fuer die Implementierung eines Betriebssystems (P-code virtuell interpretiert? wtf? Da steht die Maschine).
Fehlentscheidung war das sicher keine. Standardisiert war C auch vor Pascal, wenn ich mich nicht irre. Dass sich Implementierungen nicht an den Standard halten, damit hatte auch Pascal (genauso wie fast jede Sprache) zu kaempfen.

"Egal wie, man muss halt die "Eigenheiten" der Sprache erlernen. Und das anscheinend immer wieder neu.
Da ist schon sehr Schade."

Wenn es nicht so waere, hiesse das ja, dass alle Sprachen gleich sind. DAS waere schade.
Schlimm ist es nur, wenn man gezwungen ist, eine Sprache zu verwenden, die fuer eine konkrete Aufgabe nicht geeignet ist..
Programmiersprachen sind Werkzeuge, je unterschiedlicher die sind, umso eher wird man was Brauchbares finden.
Klar kann man einen Nagel auch mit einem Loetkolben einschlagen, aber dann darf man nicht ueber den Loetkolben meckern.

[PicNick]

C war in der Anfangszeit ein extrem einfacher und kleiner Compiler, imho eine Assembler-Codier Hilfe, die plattformunabhängigen Source-Code ermöglichte. Setzte nur eine Architektur mit Stack voraus, also zu der Zeit alles ausser den Mainframes wie IBM.
Merkt man deutlich, wenn man Assembler in C umschreiben will oder umgekehrt, das geht wie geschmiert.
Ansonsten: C is C is C.
Klagen fallen in die Kategorie "Das Leben ist ungerecht".
Als Amateur hat man eine mächtige Waffe: man kann es bleiben lassen.

[sternst]

Ein char hat immer 8 Bit.

Nein. Es hat mindestens 8 Bit.

[Klebwax]

Nein. Es hat mindestens 8 Bit.

Da gehen die Meinungen auseinander. Was auf jedenfall klar ist: sizeof(char) ist 1 und nicht >= 1. Die 1 heißt 1 Byte. Und ein Byte ist die kleinste im Speicher addressierbare (nicht unbedingt ladbare) Einheit. Und mal abgesehen von einigen Exoten mit 9 Bit pro Byte und einigen DSPs mit 16 oder 24 Bit als kleinste adressierbare Einheit kann man davon ausgehen, daß ein char 8 Bit hat. Daß ein Text in Unicode mehr als ein char pro Textzeichen braucht ist schon klar.

MfG Klebwax

[sternst]

sizeof(char) ist 1 und nicht >= 1

Richtig.

Die 1 heißt 1 Byte.

Auch richtig. Aber "Byte" heißt nicht automatisch "8-Bit".

Und mal abgesehen von einigen Exoten mit 9 Bit pro Byte und einigen DSPs mit 16 oder 24 Bit als kleinste adressierbare Einheit kann man davon ausgehen

Ah, ich verstehe, für dich sind "meistens" und "immer" einfach das Gleiche.

[PicNick]

Wenn wir pingelig wären, was wir ja nicht sind *g*, ist "adressierbare Einheit" eine andere Baustelle.

die prinzipielle Syntax von C ist jetzt schon ~40 Jahre alt. Irgendwas in diesem Thread, was nicht schon damals diskutiert wurde ?

[Thomas E.]

Hallo!


Ich erlaube mir, meinen Senf auch dazugeben zu dürfen. Ich habe ziemlich genau null Ahnung von C und bin begeisteter Bascom-Anhänger. Bei der Wahl der Programmiersprache, die ich lernen will, entschied ich mich nach langen Überlegungen immer wieder gegen C und würde auch heute noch immer kein C verwenden wollen. Mich schreckt die Syntax ab; ich finde es einfach seltsam, mit "kryptischen" Zeichen zu arbeiten (ja, die Zeichen sind nicht kryptisch, aber es kommt einem so vor). Für mich sieht Code in C irgendwie krank aus: jede Menge Strichpunkte, Doppelpunkte und andere Sonderzeichen, dafür wenig ausgeschriebene Wörter.

Natürlich gibt es auch in Bascom seltsame Dinge, aber ich fühle mich einfach mit dieser Sprache wohler.

[ePyx]

Mich schreckt die Syntax ab; ich finde es einfach seltsam, mit "kryptischen" Zeichen zu arbeiten (ja, die Zeichen sind nicht kryptisch, aber es kommt einem so vor). Für mich sieht Code in C irgendwie krank aus: jede Menge Strichpunkte, Doppelpunkte und andere Sonderzeichen, dafür wenig ausgeschriebene Wörter.

Gleiches gilt bei mir für Bascom. Ist halt Geschmackssache und daher ist es auch gut, dass man eine Wahl hat.

[PicNick]

Tommy ! Das ist ein C-Forum !
Bist du schon mal in einen Oberliga-Tischtennisverein gegangen und hast gesagt, "Ping-Pong" spielen kommt dir blöde vor ?
Was denkst du, was die Leute dir dort dann erzählen ?