Warum verwendet ueberhaupt noch irgendjemand C?

SeppJ schrieb:

Ich schreibe meine Programme einfach so runter. Und wenn ich hinterher versuche irgendetwas zu optimieren, dann sind die einzigen Optionen, die ich noch finde, technische Optimierungen wie Cache-Misses, auf die man während des Programmierens als Normalsterblicher gar nicht achten kann.

Kann ich kaum glauben. Du müsstest quasi auf alle Container/Algorithmen der STL verzichten (vielleicht bis auf std::vector). Da kann ich mir nur eine stupide Simulation drunter vorstellen. Möchtest du ein Beispiel bringen?

IBV schrieb:

dinosaur schrieb:

Python und Perl.

Was für Programme sind das?!

Gut, in Perl mache ich nur kleine Skripte.

Programmierst du mit mehreren Threads? Die Umsetzung von Multithreading in Skriptsprachen ist ein Witz, weswegen ich diese Sprachen für größere Projekte nicht ernst nehmen kann.

Ja ich verwende Multithreading und hatte damit noch nie Probleme.

Und von Laufzeitfehlern die durch Typprüfungen aufgefallen wären, halte ich auch nichts.

Hatte ich noch nie ein Problem damit. Das fällt schnell auf. Insgesamt ist die Zeitersparnis nicht dauernd ein verbose typing zu haben grösser als der Nachteil.

IDEs kommen dadurch was Code-Completion anbelangt, auch an ihre Grenzen.

Ich verwende keine Code-Completion, auch in C++ nicht. Das lenkt mich nur ab.

cooky451

dinosaur schrieb:

Kann ich kaum glauben. Du müsstest quasi auf alle Container/Algorithmen der STL verzichten (vielleicht bis auf std::vector).

Das ist Quatsch, weil ein Großteil eines Programms oft völlig Performanceunkritisch ist.

dinosaur schrieb:

Hatte ich noch nie ein Problem damit. Das fällt schnell auf. Insgesamt ist die Zeitersparnis nicht dauernd ein verbose typing zu haben grösser als der Nachteil.

Also mich hat das enorm gestört, insbesondere wenn man noch mal schnell etwas testweise ändern will, treten dann teilweise Fehler in Randsituationen zur Laufzeit auf die einem der Compiler sonst sofort mitgeteilt hätte. (Ich meine nicht umsonst gibt es static_assert.) Vermutlich gewöhnt man sich irgendwann daran, aber dass es Zeit spart kann ich mir jetzt nicht vorstellen. (Außer bei sehr kleinen Scripts.)

Mechanics

Ich kann mir auch nicht vorstellen, dass es Zeit spart, wenn man sich dran gewöhnt hat. Abgesehen davon, dass mich das auch enorm stört, dass einige Fehler unnötigerweise erst bei irgendwelchen Sonderfällen zur Laufzeit auffallen. Warum sollte die Zeitersparnis beim Tippen wichtig sein? Das ist doch völlig irrelevant. Viel wichtiger ist, später im Programm zu sehen, was man hat und was das ist. Bei jedem größeren Programm finde ich das eigentlich schon völlig unwartbar. Wenn ich irgendwo eine Funktion sehe, die einen Parameter x bekommt, woher soll ich den wissen, was das x ist und was das kann? Ist doch viel besser, wenn man den Typen gleich kennt, dann kann man sich den Typen anschauen und man kann auch sonst nichts falsch machen, weil der Compiler einen dabei unterstützt. Sonst fängt man an zu suchen, wo die Funktion alles aufgerufen wird, um rauszufinden, was man da reinbekommt, dann geht das so immer weiter, weil der Parameter über mehrere Funktionen durchgereicht wird, dann wird der Parameter irgendwo rausgeholt, wo dann auch überhaupt nicht klar ist, was das ist und man muss suchen, wo da was reingesteckt wird usw... Ich werde nie verstehen, wie jemand meinen kann, so könnte man effizienter entwickeln.
Ich musste früher auch paar größere Perl und Python Programme pflegen, die nicht von mir waren, und habe ewig nach sowas gesucht. Klar, ist ja nicht mein Programm und ich kenn mich nicht aus. Nur hätte ich in einer statisch typisierten Sprache solche Probleme überhaupt nicht. Im Grunde genommen hätte ich sowas nicht mal suchen müssen, weil auch die Fehler an sich waren oft ebenfalls auf falsche Typen zurückzuführen. Es gibt irgendwelche Strukturen oder Plugins oder was auch immer, dann wird irgendwo irgendwas geändert, und eine unwichtige Funktion vergisst man dabei und fünf Jahre später fällt auf, dass "irgendwas" nicht geht.

Nexus

Der Verlust der statischen Typsicherheit wirkt sich nicht nur auf Autocompletion aus, auch Refactoring wird zur Hölle. Du änderst in C++ die Semantik eines Parameters und änderst dessen Typ? Kein Problem, Aufrufcode kompiliert nicht. Skriptsprache: Manuell alle Aufrufe suchen und ändern, hoffen dass man keinen vergessen hat. Funktion umbenennen? Alt+Shift+R in VAX, fertig. Funktioniert semantisch und nicht nur Search&Replace, kennt daher Scopes. Zugriff auf Variable, die noch nicht existiert? Kompiliert in C++ nicht, Laufzeitfehler in Skriptsprachen. Das geht endlos weiter... Codeanalyse-Tools können einen kleinen Teil solcher Fehler auffangen, aber prinzipbedingt lange nicht alles.

Ich merke alleine schon, wenn ich in Java entwickle, wie oft ich NullPointerException s habe -- nicht selten durch vage dokumentierte Schnittstellen, die in Spezialfällen unerwartet null zurückgeben. In C++ dereferenziere ich nie Nullzeiger, weil ich mit dem Typen ausdrücken kann, ob nullptr ein gültiger Zustand ist. Insbesondere kann ich ausdrücken, dass ein Objekt immer konstruiert zu sein hat. Anhand einer Funktionssignatur in C++ kann man enorm viel über die Semantik ablesen, besonders im Bezug auf Besitzverhältnisse und Lese-/Schreibrechte. Bei Java kann man nur den unqualifizierten Datentypen erkennen, bei dynamisch typisierten Sprachen gar nichts.

Bei kleineren Skripten und Prototypen oder sehr dynamischen Programmen spielen dynamisch typisierte Sprachen ihre Stärken aus. Bei "klassischen" Softwareprojekten ab einer gewissen Komplexität kann statische Typsicherheit massiv viel ausmachen.

Dobi

Kellerautomat schrieb:

http://nuwen.net/gcc.html#whynotc

C++ is the best general purpose programming language.

Lol, bis dahin gefiel mir der Artikel eigentlich recht gut.

cooky451 schrieb:

dinosaur schrieb:

Kann ich kaum glauben. Du müsstest quasi auf alle Container/Algorithmen der STL verzichten (vielleicht bis auf std::vector).

Das ist Quatsch, weil ein Großteil eines Programms oft völlig Performanceunkritisch ist.

Genau auf das wollte ich raus. Für den Grossteil eines Programms ist C++ völlig Overkill -- aus Sicht der Performance und des Syntaxoverheads. Wenn niemand Performanceschwierigkeiten mit der Standardbibliothek bekommt dann ist offenbar Performance für die meisten kein Grund, C++ zu wählen.

dinosaur schrieb:

Hatte ich noch nie ein Problem damit. Das fällt schnell auf. Insgesamt ist die Zeitersparnis nicht dauernd ein verbose typing zu haben grösser als der Nachteil.

Also mich hat das enorm gestört, insbesondere wenn man noch mal schnell etwas testweise ändern will, treten dann teilweise Fehler in Randsituationen zur Laufzeit auf die einem der Compiler sonst sofort mitgeteilt hätte. (Ich meine nicht umsonst gibt es static_assert.)

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

Nebenbei gibt es gute Tools, pyflakes fängt dir einige Fehler während dem Code ab.

Abgesehen davon, dass mich das auch enorm stört, dass einige Fehler unnötigerweise erst bei irgendwelchen Sonderfällen zur Laufzeit auffallen.

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

Warum sollte die Zeitersparnis beim Tippen wichtig sein? Das ist doch völlig irrelevant. Viel wichtiger ist, später im Programm zu sehen, was man hat und was das ist. Bei jedem größeren Programm finde ich das eigentlich schon völlig unwartbar. Wenn ich irgendwo eine Funktion sehe, die einen Parameter x bekommt, woher soll ich den wissen, was das x ist und was das kann?

Nimm mal das als Beispiel: https://docs.python.org/3/library/argparse.html vs http://www.boost.org/doc/libs/1_55_0/doc/html/program_options/tutorial.html#idp163291912
Welcher Code ist lesberer:

// Declare the supported options.
po::options_description desc("Allowed options");
desc.add_options()
    ("help", "produce help message")
    ("compression", po::value<int>(), "set compression level")
;

po::variables_map vm;
po::store(po::parse_command_line(ac, av, desc), vm);
po::notify(vm);    

if (vm.count("help")) {
    cout << desc << "\n";
    return 1;
}

if (vm.count("compression")) {
    cout << "Compression level was set to " 
 << vm["compression"].as<int>() << ".\n";
} else {
    cout << "Compression level was not set.\n";
}

import argparse

parser = argparse.ArgumentParser(description='Process some integers.')
parser.add_argument('integers', metavar='N', type=int, nargs='+',
                   help='an integer for the accumulator')
parser.add_argument('--sum', dest='accumulate', action='store_const',
                   const=sum, default=max,
                   help='sum the integers (default: find the max)')

args = parser.parse_args()
print(args.accumulate(args.integers))

(Leider kein passendes Syntax Highlighting hier)

Ist doch viel besser, wenn man den Typen gleich kennt, dann kann man sich den Typen anschauen und man kann auch sonst nichts falsch machen, weil der Compiler einen dabei unterstützt.

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

Mechanics

dinosaur, diese Argumente sind irrelevant. Du wirst mich nicht überzeugen. Ich versuche auch nicht dich überzeugen, wenn du dynamisch typisierte Scriptsprachen magst, bleib dabei.
Im übrigen find ich den von dir geposteten PHP Code nicht lesbarer. Ich hab jedenfalls überhaupt kein Problem mit dem C++ Code. Und ich hab auch nie von 20 Zeilen Programmen gesprochen, da hätt ich auch kein Problem mit einer Scriptsprache. Ich rede von größeren Programmen mit mehreren hundert tausend oder Millionen Zeilen Code.

Dobi

@dinosaur: Ich kann glaube ich gut nachvollziehen, was du meinst. Als ich Python entdeckt habe, ging mir C++ zunächst erst ziemlich auf den Keks. Als ich dann aber Haskell kennengelernt habe, habe ich bemerkt, dass das, was mich an C++ nervte, seine Ursache gar nicht in der statischen Typisierung hatte.
Seit dem schaue ich mir alle möglichen unterschiedlichen Sprachen und Paradigmen an. Meine Abneigung gegen C++, übrigens die Sprache, mit der ich am allermeisten Erfahrung habe, hat sich wieder gelegt, und ich benutze das, was ich für das jeweilige Projekt am geeignetsten finde. Falls du den Artikel "What to know before debating type systems" noch nicht kennst, empfehle ich ihn dir hier an dieser Stelle mal.
http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html

Bier

Kellerautomat schrieb:

Ich denke STL (Person) bringt es auf den Punkt: http://nuwen.net/gcc.html#whynotc

Stephan T. Lavavey pflegt die Standard Template Library von Visual Studio, er verdient sein Geld damit. Natürlich ist die dann ganz ganz dolle und jeder Entwickler wäre ja blöd diese - und damit C++ - nicht zu benutzen. Man beißt nicht die Hand, die einen füttert (allerdings empfiehlt er auf derselben Seite GCC als Compiler ... ganz schön mutig der Kerl. Aber das hat Herb Sutter ja auch schon mal gemacht. Ich schweife ab.). Die Frage muss lauten: Warum verwendet überhaupt noch irgendjemand C anstatt C++? Eine schnelle why c++ sucks Suchanfrage auf startpage oder einer anderen präferierten Suchmaschine liefert einige kritische Ansichten zu C++:

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 (Linus Torvalds famous rant)
http://www.cpp-home.com/tutorials/244_1.htm (Why C++ sucks)
http://yosefk.com (Ich glaube der Typ hasst C++, sein Blog macht jedenfalls den Eindruck. Sein C++ FQA ist aber auch nicht schlecht.)
http://c0de517e.blogspot.de/2011/02/surviving-c.html
http://dorinlazar.ro/the-day-i-gave-up-on-cpp/
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

Kann man von halten was man will, aber völlig ohne Substanz sind diese Ansichten nunmal nicht. C++ ist eine überladene (hehe) Sprache, die viele viele Fallstricke enthält. Und was sagt Stephan über C?

(...)The problem with C is that it is so small that it doesn't contain enough support for modern programming techniques. C has insufficient support for object-oriented programming and no support for generic programming.(...)

Templates fehlen, ja. Diese mit Makros nachzubauen ist keine schöne Lösung, macht denke ich auch kaum einer. 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.

(...)For some insane reason, GNU/Linux and most GNU/Linux programs are still written in C. I believe that the underlying reason is lack of vision.(...)

Ich kann schon eine pulsierende Ader an Linus Torvalds Schläfe sehen. Gleich wechselt er in den Rage-Mode :D. Naja, was ist denn die Alternative zu C im Kernel? Ganz sicher nicht C++, weil man da die ganzen schönen Features wie exceptions und die STL eben nicht verwenden kann, zumindest nicht out-of-the-box. Was bleibt ist die Restriktion auf ein C-ähnliches subset. Kann man auch gleich C für verwenden.

Anyways, C should not be used in this day and age. C should not be learned. C should not be taught.

Und wer bringt den coolen Kids von morgen dann bei was Pointer und plain-old C-Strings sind. Die verfallen doch in eine Angststarre wenn die STL mal nicht zur Verfügung steht und sie rohe Zeiger anfassen müssen.

SeppJ

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.

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.
Und virtuelle Funktionen und Vererbung überfordern die meisten Leute sicherlich schon. Selber vtbl zu schreiben ist schon reichlich viel Aufwand.

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.