Was haltet ihr von Mono/C#?

@Amin
Dann waeren wir also doch bei "Weil die Programmierer C am besten (laengsten) beherrschen?".
Richtig! Aber das bedeutet nicht, das C++ ein schlechtes Werkzeug ist. Es heißt nur, das jemand das Werkzeug C++ nicht beherrscht. Und C ist nunmal weniger Komplex, man muß sehr wenig Basics lernen. (keine Bewertung von mir, nur eine Tatsache!) Und der C-Lösungsweg ist dann natürlich ein anderer als in C++. Um C++ ausnutzen zu können, muß man viel mehr darüber lernen. Das ist ja das, was ich mit dem "inneren Schweinehund überwinden" meine. Und das ist ja auch menschlich. ;)

Dennoch kann es in der Realitaet anders aussehen. Auf manchen Plattformen sind C-Standardfunktionen noch immer wesentlich performanter implementiert als das C++-Equivalent! (Weis der Kukuk warum) Ich finde die Tests leider nicht mehr.
Hem, weiß jetzt nicht genau was du meinst? Hast du ein Beispiel?
Weil eigentlich gibt es in C++ keine Equivalente zu C-Funktionen. Deshalb gibt es die C-Headers (zumindest die meisten) auch noch mal in C++. Nur das die sich z.B. so nennen:
Code:
#include <cmath>

double std::sin( double arg );
In C würde der wohl <math.h> heißen. Meistens inkludiert aber <cmath> einfach <math.h> und packt deren Funktionen in den std-Namespace. ;) Ist einfacher für den Compiler-Bauer. :D

Das was ich dir zusteimmen muß, ist, das C++-Libraries schlechter implementiert sein können. Ist aber weniger C++ als Sprache zurück zu führen, sondern auf den Implementierer der Library oder Compiler. Kann ja auch schlecht implementierte C-Libraries geben, was aber auf Grund des Alters von C heute eher unwahrscheinlich ist.

C++ wurde schliesslich erst 1998 das erste mal genormt, vorher hat jeder Compiler-Hersteller gemacht, was er wollte. Mittlerweile sieht die Welt anders aus, selbst Microsofts C++-Compiler ist heute sehr ISO-C++-konform. Man darf nicht vergessen, das sich die C++-Welt auch dreht.
 
Ihr vergesst aber bei Euren Rants gegen C, was in der systemnahen Programmierung (damit meine ich jetzt Sachen wie Bootloader oder bestimmte Bestandteile des Kernels) hauptsächlich gemacht wird: Bitschubserei, vorgefertigte Maschinencode-Paketchen zur CPU schieben etc. Ganz ehrlich, ich sehe nicht, wo einem C++ da helfen könnte, besseren Code zu schreiben. Er würde weder schneller (Laufzeit) noch leichter lesbar oder einfacher anpassbar. Warum also den Aufwand betreiben und die komplette Codebase umkrempeln (das meiste davon ist zumindest in Grundzügen zu einer Zeit entstanden, als man OO-Leute noch als Ketzer in ner PDP verbrutzelt hat *g*).

Für bestimmte Kernel-Bestandteile, die auf einer etwas höheren Abstraktionsebene laufen (Scheduler, Prozessverwaltung) wäre ein OO-Ansatz aber sicherlich attraktiv. Der Organisationsaufwand, der entstünde, wenn im Kernel mit zweierlei Konzepten hantiert würde, steht meiner Meinung nach aber gegen einen solchen Ansatz (Zuständigkeiten verschiedener Entwickler, Überschneidungen von Funktionalitäten, Wiederverwendbarkeit bestimmter Funktionen oder Header, etc.)
 
Die Frage zu C++ im Kernel kam neulich auch auf einer FreeBSD-Mailingliste auf. Die passendste Antwort kam von Poul-Henning Kamp: "Wie viele Leute haben wir, die die Qualität von C++ beurteilen können?"

Und zur Performance: Das nimmt sich i.d.R wenig. Wenn sich eine Sprache besser eignet als eine Andere kann man wohl auch mit 1%-2% Performanceverlust leben.
 
@Ogion! Glaube nicht, das hier jemand was gegen C gesagt hat. Aber man darf auch sagen, was C++ kann bzw. Halbwahrheiten aufräumen, oder? :confused:
Natürlich kannst du einen Bootloader oder Kernel in C schreiben:
Amin schrieb:
Denn es ist klar, das man in C ... jedes Problem lösen kann.
Das möchte ich hier nochmal deutlich machen! :) Auch große Anwendungen wie GIMP oder Blender sind in C geschrieben. Aber deshalb darf man doch trotzdem über C++ positiv reden?

Aber das was du leider verheimlichst oder vielleicht nicht weißt, ist, das du die Bit-Schubserei auch in C++ machen kannst. Ohne OOP natürlich! Nochmal: in C++ gibt es keinen OO-Zwang.

Denn C++ ist nunmal auch eine Lowlevel-Sprache wie C, du kannst auch Assembler-Code in C++-Code einbetten. Nur weil eine Sprache die gleichen Fähigkeiten hat, muß es nicht heißen, das die andere überflüssig wird. Ganz davon abgesehen, das C nützliche Features hat, die C++ nicht hat. Und das sage ich, weil es eine Tatsache ist. :)
 
Richtig! Aber das bedeutet nicht, das C++ ein schlechtes Werkzeug ist.
Ich habe mich gefragt, ob C wirklich ein besseres sein kann.

Hem, weiß jetzt nicht genau was du meinst? Hast du ein Beispiel?

Damit meine ich genau:

Das was ich dir zusteimmen muß, ist, das C++-Libraries schlechter implementiert sein können. Ist aber weniger C++ als Sprache zurück zu führen, sondern auf den Implementierer der Library oder Compiler. Kann ja auch schlecht implementierte C-Libraries geben, was aber auf Grund des Alters von C heute eher unwahrscheinlich ist.

Wobei sich die Qualitaet der Libraries den verbreiteten PC-Plattformen schon angeglichen haben sollten.

Ich habe hier noch einen Link ausgegraben, welcher das "You pay for what you get"-Argument unterstreicht.
http://unthought.net/c++/c_vs_c++.html
 
Zuletzt bearbeitet:
Die Frage zu C++ im Kernel kam neulich auch auf einer FreeBSD-Mailingliste auf. Die passendste Antwort kam von Poul-Henning Kamp: "Wie viele Leute haben wir, die die Qualität von C++ beurteilen können?"
Ein sehr gutes Zitat! Spiegelt auch das wieder, was ich sage. Aber es ist auch gut, das wenigesten nach einer Alternative (C++) gefragt wurde. Und es wurde festgestellt, das man mit C in dem konkreten Fall besser fährt. Lieber guten C-Code, als schlechten C++-Code. Eine rationale Entscheidung!
 
Die Frage zu C++ im Kernel kam neulich auch auf einer FreeBSD-Mailingliste auf. Die passendste Antwort kam von Poul-Henning Kamp: "Wie viele Leute haben wir, die die Qualität von C++ beurteilen können?"
Was uns wieder zu "Weil die Programmierer C am besten (laengsten) beherrschen?" und "... das ganze Know-How in C vorhanden ist und es einfach unvernuenftig waere eine funktionierende Basis zu aendern?" bringt, oder?

Ihr vergesst aber bei Euren Rants gegen C
Was ist ein Rant? :)
Ich will hier keine Sprache herabwuerdigen oder ihre Existenzberechtigung anzweifeln! Da ich mich momentan sehr fuer Betriebssysteme und Systemprogrammierung interessiere, will ich nur wissen, ob C aufgrund der Geschichte des Codes und der Erfahrungen seiner Programmierer verwendet wird, oder ob es darueberhinaus noch andere technische Gruende gibt.
 
Ich will hier keine Sprache herabwuerdigen oder ihre Existenzberechtigung anzweifeln! Da ich mich momentan sehr fuer Betriebssysteme und Systemprogrammierung interessiere, will ich nur wissen, ob C aufgrund der Geschichte des Codes und der Erfahrungen seiner Programmierer verwendet wird, oder ob es darueberhinaus noch andere technische Gruende gibt.
Ich würde als C++-Fan nie auf die Idee kommen, das bestehende FreeBSD in C++ umzuschreiben. Ich kann dir aus beruflicher Erfahrung sagen, das wir hier produktive Systeme beim größten Autokonzerns in Europa haben, wo das tägliche Geschäft über COBOL-Systeme abläuft. Und weißt du was? Der Code wird nicht weniger. :apaul: Das System läuft und es wird weiter gepflegt (auch neue Features). Aber andere Systeme, die bei Null anfangen, werden bei uns in Java implementiert.

Ein FreeBSD, NT-Kernel usw. wird niemand umschreiben. Weil das auch wieder neue Fehler bedeuten würde.

Und Unix-Systeme wurden in C implementiert, weil es damals noch kein C++ gab. Jetzt FreeBSD (vorallem den Kern) in C++ umzuschreiben, ist nicht wirtschaftlich. Man könnte es in C++ neu implementieren, wenn eh nichts funktionieren würde. Ist ja aber nicht der Fall.

Man könnte vielleicht in FreeBSD neue Dienste oder neue Tools in C++ implementieren, wo man den Basis-Entwicklern nicht in die Quere kommt.

Ein neues OS würde ich persönlich aber in C++ implementieren. :D
 
Zuletzt bearbeitet:
Ich habe jetzt ein bisschen in den Mailinglists herumgestoebert und offensichtlich gab es schon mehr als genug Versuche C++ in den Kernel zu bringen, die alle daran gescheitert sind, dass sie im Endeffekt nur mehr Komplexitaet gebracht haben. Es ist leichter und eleganter das ein oder andere Konzept in C nachzubilden als relativ komplexe C++-Features und die relativ komplexe Std-Library auf Kernelebene zu implementieren.
 
Kennen sollte man ziemlich viel. Je mehr Erfahrung man hat, desto weniger Unsinn entsteht. Ich kann mir eher Leute vorstellen, die meistens C programmieren und Java können/kennen als umgekehrt.

Deswegen betrachte ich oft Leute, die Java als Allheilmittel ansehen sehr skeptisch. Klar, Java ist toll, man macht nicht viel Unfug damit... aber Programmieren lernt man so nicht und ein guter Software-Entwickler wird man so auch nicht, wenn man sich vor allem "beschützen" lässt.

Ich habe nichts gegen Pointerarithmetik, auch nichts gegen Gotos, ich benutze Endlosschleifen, nutze exzessiv den Precompiler und bin ein Fan von malloc() im Gegensatz zur GC ... steinigt mich! :)
 
Ich werfe jetzt einfach so mal folgenden Link in die Runde

http://www.reactos.org/forum/viewtopic.php?f=25&t=5297

ReactOS: why C and not C++?

Antwort:
Or to sum up. We dont use C++, because GCC's C++ Compiler sucks.
jsimmons sorry C++ in OS design is common claimed as good as. When you look at the poor poor C++ standard you find its broken all over the place.

Also hat das zwei Ursachen, wie ich sehe 1. schlechter Compiler 2. jeder nutzt seinen eigenen Standard, statt den ISO-Standard


Aber ich habe nun nochmal ne Frage zu C++:
Ich lerne gerade C und bin schon recht weit vorangekommen damit. Und ich habe mir vor einem halben Jahr das Buch "C++ von A bis Z" (wahrscheinlich umsonst) gekauft. Und das liegt noch bei mir da und verstaubt jetzt langsam. Als ich es damals lernen wollte, war es mir zu kompliziert und ich habe es in die Ecke geräumt. Meint ihr wenn ich mit C fertig bin, mein C-Wissen vertiefen soll oder ob es sich lohnt, doch noch C++ zu lernen.

Ich will eher in die systemnahe Programmierung gehen, oder evtl. auch 3D. (DarkPlaces Engine ist in C)
 
Ich warte immer noch darauf, dass D endlich mal aus seinen Kinderschuhen raus kommt. Ich mag einfach das Konzept.

Von C++ hält mich diese unglaubliche Riesigkeit der Sprache ab, bis man da etwas schreibt und nach 3 jahren immernoch darüber denkt, dass es eine recht gute Lösung ist, dauert es wahrscheinlich ewig.

C ist demnächst auch ausführlich dran, aber erst werd ich zum python ninja :). Ich hätte es nicht gedacht, aber mit Python macht coden dreifach spaß.
 
Das Problem ist jetzt, dass die (H)HLLs ((Higher) High Level Languages) als Weiterentwicklung angepriesen werden. Auf der Uni ist Java die Hauptsprache. 90% der Jobangebote sind Java. Ich finde jedoch, dass man fuer ein relativ einfaches Problem, wesentlich komplexere Werkzeuge braucht, um es zu loesen. (z.b. oop, pattern, usw)
Du brauchst nicht unbedingt eine High-Level Sprache um objektorientiert zu programmieren. Ein großteil des FreeBSD Kernel-Codes den ich gelesen habe ist objektorientiert (wenn auch etwas lax). Auch GTK+, ebenfalls komplett in C verfasst, ist objektorientiert. In diesem Fall sogar sehr konsequent und strikt. Gerade das macht das Verwenden von GTK so einleuchtend und macht es auch sehr einfach Bindings in andere Programmiersprachen zu erzeugen.

Objektorientierung ist sehr hilfreich beim lösen komplexer Probleme. Wenn das bei dir nicht der Fall ist, hast du die Objektorientierung nicht wirklich begriffen.
 
We dont use C++, because GCC's C++ Compiler sucks.
Dann sollen sie halt nicht GCC benutzen, sondern einen besseren C++-Compiler. (z.B. den ICC) Was hat die Implementierungs-Qualität eines Compilers mit der Sprache zu tun? Nichts! Mir kommt es so vor, als kennen diese Menschen nur den GCC. Aber zum Glück sind solche Aussagen von ReactOS nicht auf den Rest der Welt übertragbar. Es ist nur eine Meinung von vielen. :D

Achja "because GCC's C++ Compiler sucks" ist auch eine sehr qualitfizierte Aussage. ;)
Aber ich habe nun nochmal ne Frage zu C++:
Ich lerne gerade C und bin schon recht weit vorangekommen damit. Und ich habe mir vor einem halben Jahr das Buch "C++ von A bis Z" (wahrscheinlich umsonst) gekauft. Und das liegt noch bei mir da und verstaubt jetzt langsam. Als ich es damals lernen wollte, war es mir zu kompliziert und ich habe es in die Ecke geräumt. Meint ihr wenn ich mit C fertig bin, mein C-Wissen vertiefen soll oder ob es sich lohnt, doch noch C++ zu lernen.

Ich will eher in die systemnahe Programmierung gehen, oder evtl. auch 3D. (DarkPlaces Engine ist in C)

Ich finde deine Frage sehr komisch. Warum? Weil wie soll man diese beantworten können, wenn du selber nicht weißt, ob du C++ nutzen willst. Stell dir doch folgende Frage: "Will ich C++ benutzen?"

Falls ja: dann schmeiss das C Buch weg! (symbolisch gemeint)
Falls nein: dann schmeiss das C++ Buch weg! (symbolisch gemeint)

Wenn Du kein C++ benutzen willst, dann beschäftige dich auch nicht damit.

Wenn jemand neu in die Programmierung will, und er C++ lernen will, rate ich ihm C als Einstieg ab! Weil er durch C in seiner C++-Laufbahn keinen Vorteil erlangt. Er wird durch einen vorherigen C-Einstieg eher zum "C with Classes"-Programmierer, was überhaupt nicht Sinn von C++ ist.

Und damit man mich hier nicht falsch versteht: ich rate nicht prinzipiell von C ab! Sondern nur, wenn jemand eigentlich C++ lernen will, und dem Irrglaube unterliegt, man muß dafür vorher C lernen.
Bjarne Stroustrups (Erfinder von C++) FAQ unterstreicht das ganze nochmal:
http://www.research.att.com/~bs/bs_faq.html#prerequisite

Wer C lernen und benutzen will, soll auch C lernen! :belehren:
 
Dann sollen sie halt nicht GCC benutzen, sondern einen besseren C++-Compiler.
Wenn du auf den verschiedenen Plattformen jeweils einen anderen Compiler nimmst, kommt noch mehr Mist heraus.

Was hat die Implementierungs-Qualität eines Compilers mit der Sprache zu tun? Nichts!
Was bringt die tollste Sprachspezifikation wenn aus dem Compiler dann doch nur Muell rauskommt? Nichts!
So viele tolle Sprachen sind schon an ihrer Implementierung gescheitert...
 
Zurück
Oben