C-Hasser in 10 Tagen

Noch ein dümmlicher Programmiersprachen-Flame-Thread.

Meiner Meinung nach kann man C nicht in 10 Tagen richtig lernen, also 
kanns demzufolge nur zum C-Hasser reichen. Solche Artikel sind daher 
sinnlos.

Ich würde 6 Monate Programmierpraxis veranschlagen, um mit C 
einigermaßen warm zu werden. Wer weniger investiert, kann sich keine 
Meinung über C erlauben.

Peter Dannegger schrieb:
> Meiner Meinung nach kann man C nicht in 10 Tagen richtig lernen


Gibt es denn überhaupt irgendeine Programmiersprache, die man in 10 
Tagen "richtig" lernen kann?

>Gibt es denn überhaupt irgendeine Programmiersprache, die man in 10
>Tagen "richtig" lernen kann?
Programmiersprache in 10 Tagen lernen: -JA-
Programmieren in 10 Tagen lernen: -NEIN-

D. I. schrieb:
> Das 20. Jahrhundert hat gerade angerufen, die wollen diese Homepage
> wieder haben...

Aber nur für das dev/null.

Ich finde die Seite durchaus amüsant.
Auf jeden Fall sind die Beispiele fundiert und man merkt, dass der Autor 
Ahnung von der Sprache hat, was bei dem letzten Thread eindeutig nicht 
der Fall war.
Wenn ihr damal drauf schauen würdet, würdet ihr bestimmt feststellen, 
dass der Autor da viele Sachen anspricht, die einen an C doch schön 
öfter auf die Nerven gegangen sind.

edit:
hat ja auch keiner gesagt, dass man C in 10 Tagen lernen soll.
Der Titel soll wohl eher eine Referenz auf die ganzen "Lerne X in 10 
Tagen" Bücher sein.

Stellenweise recht lustig, aber sehr schön wie er fast ausschließlich 
auf den syntaktischen Problemen herumreitet, komplett ignoriert wie C++ 
viele der Probleme löst, und von Templates nur sagt was alte Compiler 
"damals" für Probleme damit hatten und nichts darüber wie mächtig & 
elegant sie sind, und dass eigentlich kaum eine Sprache etwas 
vergleichbares hat.

Mike schrieb:
> Da musste auch ich, als erfahrener C-Programmierer, dem Autor in vielen
> Punkten recht geben.

Ja, C ist eben nicht deppensicher, man muss auch mal mitdenken.

C existiert nicht deshalb noch, weil es so gut wäre, sondern weil es so 
verbreitet ist - ein Teufelskreis. Mit Qualität hat das nichts zu tun. 
Viel von der dortigen Kritik trifft zu. Nur neige ich nicht dazu, in 
diesem Zusammenhang in Begriffen von Hass oder Liebe zu denken.

@ vn nn (wefwef_s)

>> Da musste auch ich, als erfahrener C-Programmierer, dem Autor in vielen
>> Punkten recht geben.

>Ja, C ist eben nicht deppensicher, man muss auch mal mitdenken.

Ach ja? Du jonglierst gern mit entsicherten Handgranten?

http://www.thealmightyguru.com/Humor/Docs/ShootYourselfInTheFoot.html

;-)

>Ja, C ist eben nicht deppensicher, man muss auch mal mitdenken.
==>Es gibt keine Garantie, dass (D)ein SW-Team "Deppenfrei" ist!
Wir hatten da vor einigen Jahren ein C/C++ Grossprojekt, da haben 
zahlreiche Programmierer über mehrere Jahren ihren Beitrag geliefert. 
Die SW lief schlussendlich völlig instabil, hatte seltsame Fehler, 
Abstürze und kämpfte auch mit Memory-Leakes. Wir mussten Monate 
investieren um die SW wieder stabil auf die Beine zu kriegen. Viele 
Fehler basierten auf typischen C/C++ Problemen und wären z.B. bei Ada 
nicht passiert:
-Stacküberläufe (zwischen Task-Stacks)
-Bufferüberläufe
-Nicht mehr freigegebene Objekte (kein Garbage collector in C++)
-Ungültige Referenzenn (oft im falschen Task-Kontext)

Von einer so fest gefügten Welt, wie der von Josef G 
(Beitrag "8bit-Computing mit FPGA") mag zwar mancher 
träumen, aber ich schätze, daß die fast allen sehr, sehr schnell öd und 
langweilig vorkommen wird...


Zum Artikel: Schon das erste Beispiel zeigt, wie tief der Herr und 
Meister in die Materie eingedrungen ist:

1

while(i--<10) {};

Peter S. schrieb:
> Wir hatten da vor einigen Jahren ein C/C++ Grossprojekt, da haben
> zahlreiche Programmierer über mehrere Jahren ihren Beitrag geliefert.

Sobald mehrere an einer SW arbeiten, ist eine gute Projektplanung sowie 
Dokumentation aller Schnittstellen Bedingung. Daran krankt es meistens 
und das ist nicht die Schuld des Compilers.

Auch muß jeder Programmierer alle Probleme dem Team sofort offen legen 
und nicht heimlich Würg-Arounds einbauen, bevor er die Fehlerursache 
wirklich gefunden hat.

Ist eine Fehlerursache gefunden worden, muß diese dokumentiert werden, 
damit nicht nochmal jemand reintappt.

Ich hatte mir mal ne Assemblerroutine geschrieben und nach etwa einem 
jahr sie nochmal verwendet. Dabei dachte ich, eine Instruktion wäre 
überflüssig, war sie aber nicht.

@ Peter Dannegger (peda)

>Ich hatte mir mal ne Assemblerroutine geschrieben und nach etwa einem
>jahr sie nochmal verwendet. Dabei dachte ich, eine Instruktion wäre
>überflüssig, war sie aber nicht.

Strukturierte Programmierung auf Mikrocontrollern

"Je genialer die Idee, um so nötiger der Kommentar."

;-)