Was spricht für/gegen 'C' als Programmier-Sprache ...

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich probier's einfach mal ...

    [als Beitrag zur Reihe: Was spricht für oder gegen XYZ als Programmiersprache?]

    Bislang erschienen:

    Wäre toll wenn wir es schaffen ohne gegenseitige Ellenbogen-Checks, Wertungen, ... einfach mal subjektive Meinungen zu diesem Thema hier zu sammeln.

    Mit ein bisschen Eigen-Disziplin könnte das eine durchaus brauchbare Sammlung von Pro und Contra werden.

    Vielleicht kann man das dann auf andere Sprechen ausdehnen ... dann wäre das sicher eine Art "Leitfaden" für Programmier-Einsteiger und solche, die es werden wollen.

    Wobei, wie gesagt, die Betonung auf subjektiver Meinung liegt ( was objektive Argumente aber nicht ausschliesst ).

    Ich finde an C gut, dass

    - der Code des compilierten Programms so ziemlich der schnellste nach Assembler ist

    - trotzdem ich sehr nahe an der Hardware bin

    - ich "gezwungen" bin meine Programme sorgfältig zu erstellen, um z.B. Speicherlecks oder Programm-Abstürze zu vermeiden

    - es so ziemlich für alles C-Bibliotheken gibt

    - es Pointer und Pointer-Arithmetik gibt  smiley_emoticons_hurra2.gif

    Ich finde an C nicht gut, dass

    - es gerade beim Kernel und bei Kernel-Modulen Abhängigkeiten von der Compiler-Version gibt

    - es für Einsteiger zunächst sehr viel Grundwissen erfordert

    Und nun ihr ;)

    cu,

    -ds-

  • Was spricht für/gegen 'C' als Programmier-Sprache ...? Schau mal ob du hier fündig wirst!

  • - ich "gezwungen" bin meine Programme sorgfältig zu erstellen, um z.B. Speicherlecks oder Programm-Abstürze zu vermeiden

    bin ich überall gezwungen!

    Ich finde an C nicht gut das es zwar malloc gibt aber der Speicher fragmentiert wird, wo ist die gute garbage collection hin?

    Auf diesen Fehler bin ich das erste Mal am Atari reingefallen, nach 128 malloc Anforderungen war bei TOS1.0 Schluß, dem gingen glatt die handles aus, mit TOS 1.4 wurde das auf 1024 nach hinten verlagert, aber ich habe mir malloc abgewöhnt.

    In C nervt mich das ich immer noch mit Pointer auf Pointer kämpfe und call by value und call bei ref, und neuerdings bei atomaren Zugriffen in einer ISR das leidige 8-16 Bit Zugriffsproblem am AVR.

    Deswegen immer schön weiterlernen! (und nicht die Sprache wechseln)

    An C mag ich #defines

    #define if wenn

    oder eigene Funktionen basteln

    lefts für left string,

    mids für mid string und

    rights

    hach da kommen Basicerinnerungen hoch, gruß vom ehemaligen CBM User.

    Das Kompilieren finde ich komplizierter als das Programmieren....

    doch nicht in einer guten IDE

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo zusammen,

    an C gefällt mir:

    - nach Assembler die zweit schnellsten Benchmark-Ergebnisse

    - Maschinennähe

    - universelle Einsetzbarkeit (Anwendungen, Tools, Treiber, Betriebssysteme, ...)

    Was mich an C stört:

    - Semikolons an fast allen Zeilenenden erforderlich (obwohl es meiner Meinung nach keinen Grund dafür gibt: wenn die Zeile nicht fortgesetzt werden soll fehlt einfach das Zeilenfortsetzungszeichen)

    - Pointer bilden meiner Meinung nach eine Schwelle, über die viele nicht hinauskommen - und deswegen gleich was anderes probieren

    - Lesbarkeit von C-Code ist abhängig vom Programmierer (kann lesbar sein, muss aber nicht)

    - je nach dem, wo der Programmierer die einleitenden { setzt , kann man den Code überblicken oder nicht

    Fazit:

    Insgesamt kommt niemand an C vorbei, der ernsthaft programmieren möchte.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (29. Dezember 2017 um 23:10)

  • - Lesbarkeit von C-Code ist abhängig vom Programmierer (kann lesbar sein, muss aber nicht)

    Gilt für JEDE erdenkliche programmiersprache


    - Semikolons an fast allen Zeilenenden erforderlich

    Finde ich gut! damit wird eindeutig das Ende einer Anforderung dokumentiert. Ich finde gut an Python, dass ';' ignoriert wird, macht es für mich als notorischen C Programmierer einfacher!

    - je nach dem, wo der Programmierer die einleitenden { setzt , kann man den Code überblicken oder nicht

    stimmt leider. Habe bei meinen Mitarbeitern aber immer eine Konvention durchgestetzt, bzw es gab Vorgaben der Firma. Das ist also beherrschbar.

  • Na also ... sieht doch schon mal ganz gut aus bis jetzt ... :thumbup:

    nurazur: bitte nicht die Argumente/den Eindruck anderer Poster kommentieren. Einfach nur die eigenen (subjektiven) Argumente/Eindrücke posten.

    Ich fürchte, das entgleist sonst ... und das fände ich schade.

    cu,

    -ds-

  • Es gibt zwei Arten von Programmen, die einen enthalten offensichtlich keine Fehler,

    die anderen enthalten keine offensichtlichen Fehler.

    Programme in C oder Assembler tragen ein stark erhöhtest Risiko für (Flüchtigkeits-) Fehler.

    Akzeptabel für 3-Zeiler. Gefährlich für größere Projekte, oder teuer wenn man einen entsprechenden

    Aufwand für die Fehlersuche treibt.

  • nurazur: bitte nicht die Argumente/den Eindruck anderer Poster kommentieren. Einfach nur die eigenen (subjektiven) Argumente/Eindrücke posten.

    Ich fürchte, das entgleist sonst ...

    OK.

    Ich finde C gut weil...

    - keine andere Sprache ist näher an der Hardware ausser Assembler

    - ich finde das Konzept mit den Zeigern einfach, einleuchtend und logisch

    - ich habe kein Problem mit einem Zeiger auf ein Array von Zeigern

    - sehr viele andere Programmiersprachen sind an C orientiert/angelehnt: z.B. JavaSript, PHP, C++,..

    - ich konnte C schnell lernen, man muss sich nur darauf einlassen.

    ich finde C nicht gut weil...

    - die printf Funktion ist extrem komplex und ich muss immer eine Code Referenz befragen um einen korrekten Output zu bekommen

    - die Interpretation von Strings ist in C nicht trivial, wesentlich komplizierter als in anderen Sprachen

    - dynamische Speicherbereiche zu verwalten ist schwierig, moeglich, aber eher für Fortgeschrittene...

  • C ist ein zweischneidiges Schwert. Das größte Manko ist die schlechte Typisierung. Bereits Pascal war besser in puncto Typisierung und der daraus resultierenden Möglichkeit, Fehler zur Compilezeit und nicht erst zur Laufzeit zu erkennen. Nun könnte man daraus ableiten, daß es erheblich schwieriger ist, ein sauberes C-Programm zu schreiben, als ein sauberes C++ Programm - und da ist wirklich etwas dran.

    In C++ sollte der void-Pointer eher nicht mehr auftreten und stattdessen static_cast und Co. Speicherverwaltung? Naja, die gehört weniger zur Sprache. als zur Runtime, wenngleich die Grenzen verschwimmen. Was die eine Sprache besser macht, daß reißt sie an Unzulänglichkeiten und "Versuchungen" (C# async-Krempel) mit dem Allerwertesten wieder ein. Was nützen Sprachkonstrukte der parallelen Programmierung, wenn der Anwender meint, er wisse, was er tut und ein Deadlock nach dem anderen produziert?!

    Am Ende ist es Wurst, in welcher Sprache man programmiert. Sauberen Code zu erzeugen ist wichtig. Und das ist etwas was eher sprachunabhängig ist. Das lernt man nicht vordergründig bei der Erstellung von Applikationscode sondern der Erstellung von Bibliothekscode und der Wartung eben jenes (einmal hinrotzen kann jeder).

    Drücken wir es mal so aus - ich ziehe den Hut vor Leuten, die es schaffen, Assemblercode kürzer zu schreiben, als es die Codegeneratoren heutiger Compiler vermögen und diesen über mehrere Jahre hinweg zu warten. Aber vermutlich gibt es da nur eine handvoll auf Erden...

    Anbei mal ein kleines Quiz. Wie überprüft man, ob eine Zahl eine Zweierpotenz ist?

    @ds: Sorry für meinen OT-Beitrag. Ich habe den Hintergrund vielleicht nicht ganz verstanden, wollte aber meine Meinung zum Ausdruck bringen, daß die Sprache eher von untergeordneter Bedeutung ist, deren verstandene/richtige Anwendung jedoch wesentlich wichtiger.

    Noch etwas zum Topic: Weder an C, noch an C++ mag ich die Header. Die sind so überflüssig wie ein Kropf und ermüden nur die Finger!

    @all: Rutscht alle gut rüber nach 2018!

  • Hallo schnasseldag,

    Anbei mal ein kleines Quiz. Wie überprüft man, ob eine Zahl eine Zweierpotenz ist?

    Höchtswertiges Bit ist 1, nach Rausschieben bleibt 0 übrig oder nach LEFT-ROTATE bleibt 1 übrig.


    Drücken wir es mal so aus - ich ziehe den Hut vor Leuten, die es schaffen, Assemblercode kürzer zu schreiben, als es die Codegeneratoren heutiger Compiler vermögen und diesen über mehrere Jahre hinweg zu warten. Aber vermutlich gibt es da nur eine handvoll auf Erden...

    Das wiederum ist auch nicht schwer: Wenn Du direkt in Assembler schreibst, und Du Assembler einigermaßen "beherrschst", dann ist der Code fast immer um 30 % kürzer als der von Compiler erzeugte. Das hängt mit der Compiler-Eierei zusammen. Du weißt, was du erreichen willst und kommst mit einem Minimum an Registern und Speicher aus. Ein Compiler schaufelt alle naselang Variablen auf den Stack, ruft Funktionen auf (sichert den lokalen Speicher auf den Stack, die Parameter wieder auf den Stack, in der Funktion wieder vom Stack - am Ende ist der Inhalt der Variablen a nur 1 angewachsen.

    Handcodierter Assembler-Code ist dann auch deutlich schneller als noch so optimierter Compiler-Code - auch wenn C in den Benchmarks, die ich in den letzten Wochen und überhaupt gesehen habe, die schnellste aller Compilersprachen ist. Nicht umsonst erreichen andere Programmiersprachen höhere Geschwindigkeit, wenn sie erstmal nach C übersetzen und dann mit den Bordmitteln des Betriebssystems (Linux) aus C Binärcode erzeugen.

    Ja, da hast du wieder Recht... Über mehrere Jahre hinweg zu warten ist dann was ganz Anderes. Bei einem Kunden hatte ich urplötzlich Code-Reviews an der Backe, weil ich in der Abteilung der einzige war, der programmieren konnte und offensichtlich nicht ganz ausgelastet war. Die Sache habe ich ir ganz einfach gemacht. Alten Code in Excel, neuen Code ein Spalte daneben, solange herum geschoben, dass die meisten Übereinstimmungen entstanden und dann kommentiert, warum aus Zeilen des alten Codes genau die neuen Zeilen entstanden sind. Ging irre schnell und fokussierte die Aufmerksamkeit auf das Wesentliche. (Es ging da um CNC-Programme eines 5-Achs-Laserschweißsystems, das ich qualifiziert und dessen Schweißprogramme ich validiert hatte.)


    @all: Rutscht alle gut rüber nach 2018!

    Ja, gern ... aber wie soll das denn gehen? Wir haben hier keinen Schnee, keinen Frost. Der Wetterfritze hat für die fragliche Nacht 16 °C prognostiziert. Das sieht wieder so aus wie vor ein paar Jahren: Heizung aus, kurze Hose, T-Shirt und dann raus auf die Straße mit den Nachbarn zum neuen Jahr anecken.

    ;)


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    4 Mal editiert, zuletzt von Andreas (30. Dezember 2017 um 00:24)

  • SCNR dreamshader : Die Antwort ist... 42!

    das war leicht und da komme ich auch mit ohne mich zu überanstrengen :danke_ATDE:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • 0 ist nüscht und XOR im Kopf ist heute nicht mehr so meins.

    Das war früher näher am Prozzi anders

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Andreas: Geht in die richtige Richtung, benötigt aber immer noch eine Schleife...

    Denkansatz: Subtrahiere 1 und XOR mit dem Original. Was kommt raus?

    NÜSCHT! 0 bei Zweierpotenzen

    Ungleich Null bei Summen von Zweierpotenzen...

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Andreas: Deinem "Assembleroptimismus" kann ich nicht generell folgen. Der VS 2.0 Compiler (dessen Code hatte ich mir vor 15 Jahren mal etwas angeschaut) erzeugte bereits für den Aufruf virtueller Funktionen Konstrukte der Art call [ESI+offset], welche taktzyklenmäßig schneller ware, als calls zu relozierten Adressen, da der Op-Code kürzer war. Templatefunktionen gleicher Speichergröße bei unterschiedlichen Typen (z.B. enum/int) erkannte der Linker und eliminierte solche Dupletten über Module hinweg. Und das alles bei einer handvoll Registern! Jetzt willst Du mir sagen, daß die menschliche Birne bei 32 ARM-Registern oder einer ebensolchen Anzahl ATMega-Registern noch den Überblick behält? Also meine Birne jedenfalls nicht :) Da lobe ich mir die "heile Welt der Objekte" und Codegeneratoren :-))

  • Hi schnasseldag,

    wie Du weißt, hatte ich ja letztes Jahr recht viel mit Assembler gemacht. und immer wieder verglichen, was macht der C-Compiler aus C-Code, der das gleiche macht.

    Da fiel mir immer wieder was ein, was den aus C erzeugten Assembler-Code deutlich kürzer machte. Viele Sachen ließen sich dann auch nach etwas Trickserei mit ganz anderen Assembler-Befehlen umsetzen, die erst nach Tricksereien anwendbar waren. Außerdem ist es so, je intensiver Du einen C-Code in Objektcode bzw. Binärcode optimieren lässt, umso anfälliger soll das Ergebnis werden. Wie gesagt, aus Sicht der Software-Validierung kräuseln sich mir da die Haare, weil man da ganz schnell in Bereiche kommt, wo das Vertrauen in das Ergebnis schwindet - was man ja genau durch die Validierung erreichen wollte.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!