Ein interessanter Artikel: http://www.henning-thielemann.de/CHater.html Da musste auch ich, als erfahrener C-Programmierer, dem Autor in vielen Punkten recht geben.
:
Verschoben durch User
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-
Das 20. Jahrhundert hat gerade angerufen, die wollen diese Homepage wieder haben...
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." ;-)