Ohne "C" bräuchten wir keine Debugger

[derNeue]

Sowas hat meist "historische Gründe". I.A.gibt es schon Programme, Bibliotheken, ... die in C (oder auch anderen Sprachen - FORTRAN und COBOL sind auch immer noch verbreitet) geschrieben sind. Diese ganzen Sachen auf etwas anderes zu heben kostet Geld und Zeit. Wenn man das nicht gleichzeitig mit wesentlichen Neuerungen verkaufen kann, dann bleibt das eben aus.

viele Grüße
Andreas (der seit Jahren kein Problem mit C hat )

Mh, das klingt natürlich logisch, und das wusste ich nicht, bin eben bloß ein kleiner Hobbyprogrammierer, der gerade die ersten Schritte in C hinter sich hat


MfG Dennis

[Siro]

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.
Also wird Gott und die Welt behaupten, das "C" gut ist.
Ich wüste jetzt nicht annähernd, was es in Pascal nicht gab oder gibt was man in C angeblich Hardwarenäher hätte programmieren können.
Ebenso in PLM80, das war auch eine "frühe" Sprache, die ich absolut super fand.
Ich weis aber vieles, was ohne Umwege in Pascal funktioniert, was man dem "C" erstmal mühsam beibringen muss.
Ich will ja auch garnicht darüber entscheiden welche Hochsprache nun gut oder schlecht ist, aber C liegt bei mir jenseits jeder Vernunft.
Das ist jetzt aber kein Angriff, sondern meine völlig private Meinung.
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.

ich hasse zum Beispiel solche Aussagen:
Normalerweise, vermutlich, meistens. Abhängig von... Je nachdem...
Das ist für mich Chaos Programmierung.
Und ich find es sehr Schade, daß leider kaum etwas genormt wurde.
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
Ein Bool (TRUE) ist alles was nicht 0 ist. Das wär doch eindeutig gewesen, und andere Sprachen haben diese Festlegung.
Aber nicht nur "C" schafft diese Verwirrungen:
Ein Word in Pascal war immer 16 Bit,
nachdem ich mich mit den Cortex M3 Controllern vergnüge ist ein Word plötzlich 32 Bit. Das führt unweigerlich zu Verwirrungen.
Hätte man doch Doubleword lassen können. Also nicht nur "C" ist nicht eindeutig.


warum muss ich beispielsweise
if (irgenwas == etwas)
in Klammern setzen und warum muss die Abfrage "besonders" gleich sein, also doppelt ==
Oder eine einfache Abfrage
if (blabla)
warum muss ich "blabla" im Klammern setzen ?
Mathematisch völliger Blödsinn. Einen einzelnen Ausdruck in Klammern zu setzen.
Das macht den Code (meiner Meinung nach) nur unnötig unübersichtlich.

warum muss ich was "casten" wenn ich mit 2 gleichen Datentypen arbeite ?

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

Egal wie, man muss halt die "Eigenheiten" der Sprache erlernen. Und das anscheinend immer wieder neu.
Da ist schon sehr Schade. Aber sonst bräuchten wir das Forum hier ja auch nicht
Ich wünsche allen einen Bugfreien Start in die neue Woche.
Siro

[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

[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 ?

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