Warum verwendet ueberhaupt noch irgendjemand C?

[cooky451]

dinosaur schrieb:

Syntaxoverheads.

Ich glaube die meisten Leute hier (inklusive mir*) benutzen C++ nicht primär wegen der Performance, sondern weil ihnen die Sprache an sich gefällt. Dass Programme dann dazu auch noch automatisch relativ flott** sind und man wenn man möchte/es benötigt wird hochperformanten low-level Code schreiben kann kommt nur noch dazu.

* Also sagen wir mal so. Ich halte C++ für einen riesigen mit der Zeit gewachsenen Haufen Scheiße der mehr oder weniger schon unfixable geworden ist, aber trotzdem noch für die mit Abstand beste Sprache unter den "Großen" (C#/C++/C/Java), und sicherlich 100 mal besser als jede Scriptsprache die zum schreiben größerer Software misbraucht wird.

** Und mit flott meine ich flott und nicht performant, oder wie auch immer man das definieren will. Heißt, wenig konstanter Overhead. Ja, man glaubt es kaum, aber so tolle Algorithmen man in Java auch schreiben kann die 0x777 Octocore CPUs gleichzeitig benutzen, ändert das leider nichts daran dass JDownloader 1-2 MINUTEN braucht um beim Starten in die Pötte zu kommen.

dinosaur schrieb:

Glücklicherweise kann man den Fehler gleich on the fly korrigieren und muss nicht stundenlang auf den Compiler warten.

Jap, Compile-Time kann definitiv ein Problem sein (und ist einer der Gründe warum C++ atm Müll ist), aber seien wir mal ehrlich, auch bei mittelgroßen Projekten wenn man nur halbwegs auf die Abhängigkeiten achtet hält es sich trotzdem im Sekundenbereich für Änderungen an einer Datei, sogar wenn's ein Header ist. Das ist mir dann doch noch lieber als Laufzeitfehler.

dinosaur schrieb:

Sonderfälle fängt einem das Typsystem auch nicht ab.

Eh ja doch das ist ja gerade der Punkt, mit Sonderfällen ist hier nicht etwas gemeint was beim Programmieren selten auftritt, sondern etwas das zur Laufzeit selten auftritt. Wobei das Typsystem dir natürlich garantiert dass da immer alles konsistent ist.

dinosaur schrieb:

Benannte Arguments siehst du beim Aufruf, den Typen musst du die jedesmal aufs Neue herausfinden.

Wie meinst du das? Also VS zeigt einem beim Tippen beides an.

[Ethon]

Die Lösung ist D. Die Performance von C++ ohne den Features modernerer Sprachen nach zustehen.

[Dravere]

IBV schrieb:

Einfachheit würde ich sagen. Der kompilierte Code ist außerdem auch deutlich kompakter, was bei Microcontrollern nicht unerheblich ist.

Ich möchte noch hierzu was schreiben. Derzeit schreibe ich gerade Programmcode für einen MSP430FR5739 in C++. Ich möchte darauf hinweisen, dass dies bedeutet, dass mir 16 KiB an FRAM und 1 KiB an RAM zur Verfügung steht. Ich verwende Template-Metaprogramming. Ich habe bewusst verschiedene Tests gemacht, um zu schauen, ob mein C oder C++ Code grösser ist und konnte lustigerweise mit C++ und Templates zum Teil kompakteren Code schreiben. Unwesentlich und nicht wirklich erwähnenswert, aber trotzdem lustig in Hinsicht auf die dauernden unbegründeten Vorwürfe

Dass man mit C kompakteren Code für Mikrokontroller schreiben kann oder dass C++ Templates unweigerlich zu "Code bloat" führen, halte ich für ein haltloses Gerücht. Es ist schlussendlich halt immer wieder die Frage, wie man seine Werkzeuge nun einsetzt.

[SeppJ]

Dravere schrieb:

Dass man mit C kompakteren Code für Mikrokontroller schreiben kann oder dass C++ Templates unweigerlich zu "Code bloat" führen, halte ich für ein haltloses Gerücht. Es ist schlussendlich halt immer wieder die Frage, wie man seine Werkzeuge nun einsetzt.

Genau. Gerade die Templates führen zu dem Gegenteil von dem, was der Laie zunächst denkt: Sieht aus wie die Mutter aller Verallgemeinerungen. "Das kann doch gar nicht optimal sein", denkt man zunächst. Führt aber am Ende dazu, dass der Code ziemlich stark optimiert wird, eben weil der Compiler bei der Codeerzeugung nicht mehr das verallgemeinerte Konstrukt sieht, sondern eine Version, bei der alles bis ins kleinste Details bekannt ist.

Das ist dann quasi das, was der C-Experte mit Makros machen würde. Aber eben ohne die (ziemlich starken!) Nachteile von Makros. Und eben diese Makros sind sicherlich unter den ersten Features, die oben genannter Gerüchteverbreiter zuerst nennen würde, wenn er erklären würde, warum idiomatisches C schneller wäre als idiomatisches C++.

[cooky451]

Ethon schrieb:

Die Lösung ist D.

Wäre schön, aber D macht leider noch mehr falsch als C++, und man dachte schon das sei gar nicht mehr möglich. (Ich rede vom GC falls das mittlerweile nicht schon allen klar ist, und ja man kann ihn abstellen, das ändert aber nichts daran dass die Sprache daran ausgerichtet ist und keine attraktiven Alternativen anbietet.)

Rust ist mehr oder weniger das Einzige was vielversprechend aussieht, das steckt aber halt noch in Kinderschuhen. Aber es macht zumindest Hoffnung.

[hustbaer]

Bier schrieb:

Objektorientierte Programmierung ist in C aber nun wirklich nicht schwierig. Ob ich nun

class A
{
    public:
        int DoSomething() const;
    private:
        int x;
        int y;
};

int A::DoSomething() const
{
    return 4*x + 3*y + 5;
}

oder

typedef struct A {
    int x;    // private member
    int y;    // private member
} A;

int A_DoSomething(const A* this)
{
    return 4*this->x + 3*this->y + 5;
}

schreibe, sollte niemanden überfordern. Mehr ist es doch im Grunde nicht. Vererbung? Virtuelle Funktionen? Auch alles kein Problem, muss man halt die vtbl selbst bereitstellen. Auch das überfordert niemanden. Falls doch liegt das Problem nicht bei C.

Du musst in C dafür viel mehr Code schreiben, sinnfreien Boilerplate-Code. C++ nimmt dir das ab. Das ist gut - super gut sogar. Weil der sinnfreie Boilerplate-Code das Programm aufbläht und dadurch weniger gut lesbar macht (mehr noise) und zusätzliche Fehlerquellen schafft.

Weiters fehlen in C Exceptions + dem deterministischen Aufruf der nötigen Destruktoren während des Stack-Unwinding. Was neben den bereits erwähnten Templates mMn. so ziemlich das wichtigste Argument für C++ bzw. gegen C ist.

[Bier]

SeppJ schrieb:

Das ist zwar Objektorientierung nach der Lexikondefinition, aber die richtig coolen Sachen, die man damit in C++ und anderen Sprachen machen kann (automatische Konstruktoren und Destruktoren sind so gut!), kann man damit eben nicht machen.

Ja RAII ist gut, keine Frage (ich nehme an, darauf wolltest du hinaus). Ich würde das Konzept OOP jetzt aber nicht an Konstruktoren und Destruktoren festmachen, deshalb auch mein Lexikonbeispiel. Als Konstruktor kann ja zumindest eine manuell aufzurufende Init-Funktion dienen. Destruktoren werden da schon schwieriger. Standard C wird da nicht weiterhelfen können (setjmp ist wohl eher unattraktiv). Unter Windows mittels Microsoft Extensions kann man seinen Code zumindest in ein __try{} __finally{} stecken. Seine Destruktoren ruft man dann eben manuell im __finally-Block auf. Ob GCC was ähnliches bietet weiß ich nicht.

SeppJ schrieb:

Und virtuelle Funktionen und Vererbung überfordern die meisten Leute sicherlich schon. Selber vtbl zu schreiben ist schon reichlich viel Aufwand.

Ach, so schlimm ist das nicht: http://milotshala.wordpress.com/2012/02/21/virtual-functions-in-c/. Dürfte jeder nachvollziehen können.

hustbaer schrieb:

Du musst in C dafür viel mehr Code schreiben, sinnfreien Boilerplate-Code. C++ nimmt dir das ab. Das ist gut - super gut sogar. Weil der sinnfreie Boilerplate-Code das Programm aufbläht und dadurch weniger gut lesbar macht (mehr noise) und zusätzliche Fehlerquellen schafft.

Niemand behauptet, dass solche Nachbauten in C nicht verbose und error-prone sind. Der Punkt ist der, dass man auch in C viele schöne Sachen haben kann und diese nicht schwer zu verstehen und anzuwenden sind.
EDIT: Natürlich kann man dann auch gleich C++ verwenden.

[Ethon]

cooky451 schrieb:

Ethon schrieb:

Die Lösung ist D.

Wäre schön, aber D macht leider noch mehr falsch als C++, und man dachte schon das sei gar nicht mehr möglich. (Ich rede vom GC falls das mittlerweile nicht schon allen klar ist, und ja man kann ihn abstellen, das ändert aber nichts daran dass die Sprache daran ausgerichtet ist und keine attraktiven Alternativen anbietet.)

Rust ist mehr oder weniger das Einzige was vielversprechend aussieht, das steckt aber halt noch in Kinderschuhen. Aber es macht zumindest Hoffnung.

Gut, das mit dem GC schmeckt einigen nicht (ich finde es hammergeil) und auch D macht Fehler.
Aber bei den Unmengen an Mist die sie im Vergleich zu C++ bereinigt haben kann ich mir echt nicht vorstellen dass D mehr falsch macht.

[SeppJ]

Bier schrieb:

...

Man kann also in C mit viel Aufwand und Disziplin erreichen, was es anderswo kostenlos dazu gibt. Ich denke, das hat niemand bezweifelt.

[Bier]

SeppJ schrieb:

Man kann also in C mit viel Aufwand und Disziplin erreichen, was es anderswo kostenlos dazu gibt. Ich denke, das hat niemand bezweifelt.

Bier schrieb:

EDIT: Natürlich kann man dann auch gleich C++ verwenden.

Allerdings reden wir hier nur von einem überschaubaren C with classes-subset von C++. Es gibt Leute, die das zusammen mit der Komplexität der restlichen Sprache nicht als kostenlos bezeichnen würden. Mich selbst meine ich damit nicht einmal.

[hustbaer]

Bier schrieb:

hustbaer schrieb:

Du musst in C dafür viel mehr Code schreiben, sinnfreien Boilerplate-Code. C++ nimmt dir das ab. Das ist gut - super gut sogar. Weil der sinnfreie Boilerplate-Code das Programm aufbläht und dadurch weniger gut lesbar macht (mehr noise) und zusätzliche Fehlerquellen schafft.

Niemand behauptet, dass solche Nachbauten in C nicht verbose und error-prone sind. Der Punkt ist der, dass man auch in C viele schöne Sachen haben kann und diese nicht schwer zu verstehen und anzuwenden sind.
EDIT: Natürlich kann man dann auch gleich C++ verwenden.

Genau das meine ich ja: es gibt einfach kaum echte Vorteile die C gegenüber C++ hat. Die paar Kleinigkeiten die C mehr kann (z.B. VLAs, restrict, relaxed union semantics) sind selten wichtig. Umgekehrt kann C++ aber ein paar Dinge bieten die einem oft einiges an Arbeit bzw. an Fehlerquellen abnehmen/einsparen. Und dort wo man - z.B. wegen Performance - dann C-style programmieren will, kann man es in C++ ja noch genau so.
Bzw. die meisten Toolchains unterstützen sogar "echtes" C (d.h. inklusive VLAs, restrict, relaxed union semantics) im selben Projekt mit C++ zu mixen.
=> Ich sehe keinen Grund reine C Projekte zu machen.

Ausnahmen sind natürlich Sachen wie z.B. Kernel ohne C++ Unterstützung oder Projekte wo Leute mit einer Einstellung ala Torvals (sinngemäss "C++ Programmierer können alle nicht programmieren") mitzureden haben.

[cooky451]

hustbaer schrieb:

Ausnahmen sind natürlich Sachen wie z.B. Kernel ohne C++ Unterstützung

Nicht mal da würde ich auf C++ verzichten wollen, auch die reinen Sprachfeatures ohne Standard-Library und ohne Exceptions sind schon ziemlich nett.
(Ich vermute mal dass mit C++ Unterstützung die Library gemeint ist, weil g++ kann man ja afaik mit dem gcc kompilieren.)

[Tobias Gerg]

Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)

Von daher ist man gezwungen C einzusetzen. Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.

Gruß
Tobi

[Marthog]

Tobias Gerg schrieb:

Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)

Das zaehlt heutzutage aber nicht mehr, denn es reicht, einen compiler fuer llvm-code anzubieten und schon hat man nicht nur den C-compiler, sondern auch gleich noch mehrere andere Programmiersprachen dabei.

Tobias Gerg schrieb:

Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.

Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll und ich denke, man heutzutage von jedem Softwareentwickler erwarten kann, auch objektorientierte Programmierweisen zu koennen. Ich erwarte die Bereitschaft, neuere Programmiersprachen zu lernen und ich erwarte von Firmen, dass sie ihre Mitarbeiter ggf. zu entsprechenden Fortbildungen schicken.

[hustbaer]

Marthog schrieb:

Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll und ich denke, man heutzutage von jedem Softwareentwickler erwarten kann, auch objektorientierte Programmierweisen zu koennen. Ich erwarte die Bereitschaft, neuere Programmiersprachen zu lernen und ich erwarte von Firmen, dass sie ihre Mitarbeiter ggf. zu entsprechenden Fortbildungen schicken.

Da erwartest du dir ziemlich viel.
In vielen Firmen wird's das einfach nicht spielen.

[Mechanics]

Marthog schrieb:

Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll

Ach, Quatsch. Ich bin noch keine 30 und hab schon lange keine neue Sprache mehr gelernt. Seh ich auch überhaupt nicht ein. Die "wichtigen" weitverbreiteten Sprachen kann ich alle schon lang, und irgendwelche neuen Hypes mach ich nicht mit. Mich interessiert weder D noch Go. Hab in der IT mittlerweile andere Interessen und würd sicher keine Freizeit damit verschwenden, von sich aus irgendwelche Programmiersprachen zu lernen. Außer natürlich, ich würde die Sprache für irgendwas brauchen oder die würde mich aus irgendeinem Grund interessieren. Ist in den letzten Jahren aber eben nicht vorgekommen.

[Marthog]

hustbaer schrieb:

Da erwartest du dir ziemlich viel.
In vielen Firmen wird's das einfach nicht spielen.

Weiss ich. Ich habe nur geschrieben, wie es sein sollte.

[hustbaer]

@Marthog
Inwieweit entkräftet die Tatsache/Behauptung/Meinung dass etwas nicht wahr sein sollte ein Argument?

[Marthog]

hustbaer schrieb:

Inwieweit entkräftet die Tatsache/Behauptung/Meinung dass etwas nicht wahr sein sollte ein Argument?

Firmen sollten ihre Mitarbeiter entsprechend fortbilden, damit die auch etwas anderes als C koennen. Das machen sie nicht, aber dennoch ist das kein vernuenftiger Grund, die Programme in C zu entwickeln, sondern fuehrt der Antwort, dass C verwendet wird, weil die Entwickler/Firmen inkompetent sind.

[Bitte ein Bit]

Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)

Kenne Ähnliches mit C Comilern, wo casts auf andere Datentypen des öfteren fehlerhafte Ergebnisse liefern. Ist vermutlich nur eine Frage des Alter des Compilers.

Von daher ist man gezwungen C einzusetzen. Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.

Würden sie doch nur C beherschen.

Nur weil man die grundlegenden Sprachmittel verstanden hat, heißt das noch lange nicht dass man die Sprache beherscht, geschweige denn die Grundkonzepte der Softwareentwicklung verstanden hat.

C ist für meinen Geschmack eine sehr offene Programmiersprache. Datenkapslung ist aufwendig nachzubauen.

Das beginnt schon bei private Membern. Will man dies nachbauen muss man entweder das Handle Konzept nutzen, oder man weicht das private Konzept auf und deklariert ein Member als private, und dokumentiert dies. Und die fehlt oft.