Unterschied c c++ c#

[Gast]

Na du pickst aus einem C-Kernel Stellen raus die nicht gefallen, also will ich aus einem im Umfang vergleichbaren C++-Kernel Stellen rauspicken die mir nicht gefallen. Naja, eigentlich wollte ich nur dezent darauf hinweisen, dass der Vergleich hinkt weil es eben keine Vergleichsmöglichkeit gibt.

[Sebastian Pizer]

Tim schrieb:

Na du pickst aus einem C-Kernel Stellen raus die nicht gefallen, also will ich aus einem im Umfang vergleichbaren C++-Kernel Stellen rauspicken die mir nicht gefallen. Naja, eigentlich wollte ich nur dezent darauf hinweisen, dass der Vergleich hinkt weil es eben keine Vergleichsmöglichkeit gibt.

Ich habe die Stellen nicht rausgesucht, weil ich sie schlecht fand -- zumindest nicht für C Maßstäbe -- sondern weil man dort sehen kann, wie Dinge programmiert wurden, welche der C++ Compiler automatisch und besser hätte generieren können. Ich habe das Beispiel gebracht, weil es meiner Meinung nach den C++ Gegnern, welche so etwas in C schreiben würden, ordentlich den Wind aus den Segeln nimmt, wenn sie über diese C++ Features schimpfen ("langsam", "Speicheroverhead", siehe c++ performance).

Linus Torvalds schrieb:

[...] In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap. [...]

LOL! Herrlich! Was ist denn dann kobject ?

Der Punkt ist: In C hätte man das auch nicht viel besser machen können (sozusagen schon "optimal" in C). Ich kann die Schuld also nicht auf den Programmierer schieben. In C++ schon. In C++ hätte man es besser machen können. Es geht hier (bei mir) um das, was die Sprachen leisten (können). So ist der Vergleich meiner Meinung nach um einiges sinnvoller als zwei völlig verschiedene Kernel zu nehmen und dann da mal drüber zu gucken und "ugly code" zu suchen.

Wenn Du aus einem vergleichbaren C++ Kernel etwas raus pickst, was Dir nicht gefällt, dann zeig mir aber auch bitte eine C Version, die Dir besser gefällt. Dass Dein "eleganteres C Design" auch in C++ möglich wäre, muss ich hoffentlich nicht erwähnen. Hier kann ich die Schuld also auf den Programmierer schieben. Das ist kein Argument mehr für eine schlechte Programmiersprache.

...wundert mich immer wieder, wie man bei so etwas die Stärke von C++ ignorieren kann. Ich sehe hier in der C Version weitaus mehr Fallstricke. Die C++ Version ist schön lesbar. Nein, aber zugeben darf man das nicht. Da muss man ausweichen. "Der Vergleich hinkt". Is klar...

Gruß,
SP

[TrollEyes]

Sebastian Pizer schrieb:

In C++ hätte man es besser machen können. Es geht hier (bei mir) um das, was die Sprachen leisten (können).

Es ist wohl kein Kunststück, wenn man ein Beispiel wählt (hier statisches, C++-ähnliches OOP, Klassen mit Destruktoren), für das die eine Sprache schon von Haus aus gemacht ist, um dann zu zeigen, in welcher Sprache sowas weniger Handarbeit erfordert. Die Frage, ob der Einsatz von C++ anstatt C im Linux-Kernel grundsätzlich einen signifikanten Vorteil hätte, kannst Du so nicht beantworten. Dazu müsste man viele andere Faktoren berücksichtigen, die ich hier aber nicht aufzählen möchte, damit kein Flamewar losbricht. Aber falls es Dich interessiert, was Microsoft zu C++ im Windows-Kernel meint, dann schau dir mal das an.

Sebastian Pizer schrieb:

Linus Torvalds schrieb:

[...] In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap. [...]

LOL! Herrlich! Was ist denn dann kobject ?

Er befürchtet unter anderem, dass Entwickler sonst C++ OOP an Stellen einsetzen würden, an denen es unnnötig oder sogar nachteilig ist. Im Userland darf man z.B., nach Lust und Laune, einen std::string hier und ein std::vector dort benutzen. Im Kernel aber gilt das nicht mehr.

Ich finde, du bist einfach viel zu emotional bei der Sache.

[Gast]

Sebastian Pizer schrieb:

...wundert mich immer wieder, wie man bei so etwas die Stärke von C++ ignorieren kann. Ich sehe hier in der C Version weitaus mehr Fallstricke. Die C++ Version ist schön lesbar. Nein, aber zugeben darf man das nicht. Da muss man ausweichen. "Der Vergleich hinkt". Is klar...

Wo ignoriere ich hier die Stärke von C++ in diesem Fall? (edit: Mit "in diesem Fall" meine ich nicht den Kernel)

Ein anderes Thema: In meinem Code ist so ziemlich jede zweite Variable eine globale Größe. Was sagst du dazu?

[Sebastian Pizer]

TrollEyes schrieb:

Es ist wohl kein Kunststück, wenn man ein Beispiel wählt

Nun, es basiert auf dem kobject-Design des Linux Kernels und ist nicht etwas, was ich mir komplett selbst ausgedacht habe. In Verbindung mit der "object model crap"-Geschichte finde ich das sehr interessant.

TrollEyes schrieb:

Die Frage, ob der Einsatz von C++ anstatt C im Linux-Kernel grundsätzlich einen signifikanten Vorteil hätte, kannst Du so nicht beantworten.

Hatte ich auch gar nicht vor. Von mir aus können sie machen, was sie wollen.

TrollEyes schrieb:

Ich finde, du bist einfach viel zu emotional bei der Sache.

jepp, mag sein ... muss zugeben, dass der Blick in den Linux Kernel Quellcode meinem Ego gut getan hat.

Tim schrieb:

Wo ignoriere ich hier die Stärke von C++ in diesem Fall?

Nicht? Sorry. Das kommt irgendwie so rüber, wenn man nur den einen oder anderen Punkt aufgreift und kritisiert. Ich fand das Beispiel sehr erhellend. Ein negativer Kommentar dazu sah nach genereller Ablehnung aus.

Tim schrieb:

Ein anderes Thema: In meinem Code ist so ziemlich jede zweite Variable eine globale Größe. Was sagst du dazu?

Kommt drauf an. Kann ja durchaus Sinn machen. Kann ich so nicht beurteilen. Aber "jede zweite" klingt schon nach ungewöhnlich viel. Es hat aber recht wenig mit der Sprachdiskussion zu tun.

over and out,
SP

[Gast]

Sebastian Pizer schrieb:

Ich habe das Beispiel gebracht, weil es meiner Meinung nach den C++ Gegnern, welche so etwas in C schreiben würden, ordentlich den Wind aus den Segeln nimmt, wenn sie über diese C++ Features schimpfen ("langsam", "Speicheroverhead"

Ich sehe es auch so, dass C gegenüber C++ keine Vorteile hat, aus einem einfachen Grund: man kann in C++ wie in C programmieren. Es besteht kein Zwang zur Verwendung von Klassen, Templates, Vererbung oder der STL. Wo also bestimmte C++ Features nicht angebracht sind, da benutzt man sie einfach nicht und fertig. Benutzer anderer Sprachen, seien es nun C#, Java, Python oder was anderes, könnten vielleicht das eine oder andere an C++ bemängeln, was ihre Sprache besser kann. Aber C-Programmierer können das nicht, weil mit C++ alles (und mehr) möglich ist was in C auch geht. Ich möchte gern ein glaubhaftes Argument hören, warum man C C++ vorziehen sollte. Aber ich glaube, es gibt keins.

[Gast]

Sebastian Pizer schrieb:

Nicht? Sorry. Das kommt irgendwie so rüber, wenn man nur den einen oder anderen Punkt aufgreift und kritisiert. Ich fand das Beispiel sehr erhellend. Ein negativer Kommentar dazu sah nach genereller Ablehnung aus.

Ähm, du greifst doch auch nur den ein oder anderen Punkt heraus. Willst du Sprachen gesamtheitlich vergleichen musst du halt auch schauen was wo wie warum gemacht wird. Dass du vereinzelte Teile des Linux-Kernels mit C++ sauberer implementieren könntest tut da weniger zur Sache.

Sebastian Pizer schrieb:

Tim schrieb:

Ein anderes Thema: In meinem Code ist so ziemlich jede zweite Variable eine globale Größe. Was sagst du dazu?

Kommt drauf an. Kann ja durchaus Sinn machen. Kann ich so nicht beurteilen. Aber "jede zweite" klingt schon nach ungewöhnlich viel. Es hat aber recht wenig mit der Sprachdiskussion zu tun.

War mehr ein Test. Die meisten Leute schreien gleich wild "bäh" ohne zu überlegen, du nicht. Das ist hoch anzurechnen

Z schrieb:

Ich möchte gern ein glaubhaftes Argument hören, warum man C C++ vorziehen sollte. Aber ich glaube, es gibt keins.

Such mal die Gründe nicht bei dem was C++ auf dem Papier alles mehr kann. Dabei denke ich an so Sachen wie Verfügbarkeit von Tools, Compilern aber auch Fachleuten.
Außerdem vertrete ich die Meinung, dass eine Vielzahl an Sprachmöglichkeiten hinderlich sein kann. Sieht man bereits hier: Es gibt Leute die argumentieren, dass man "in C++ auch C schreiben kann" und es gibt Leute die argumentieren, dass man die Komplexität von C++ dadurch meistern kann, dass man Grundlagen (low-level String-Handling, einfache Arrays, etc. pp.) erst gar nicht direkt lernt und gleich alles mit STL&Co erledigt. Stell dir mal ein ficktives Projekt vor wo Leute aus unterschiedlicher Richtung kommen und wie dort die gemeinsame Schnittmenge aussehen könnte. So mag C++ gerne mehr können, aber wenn das "mehr" nicht konsequent genutzt wird kriegst du Salat.

[Gast]

Tim schrieb:

Dabei denke ich an so Sachen wie Verfügbarkeit von Tools, Compilern aber auch Fachleuten.

Wenn man Compiler benutzen muss, die den C++ Standard nicht vollständig beherrschen oder Leute beschäftigt, die von bestimmten C++ Features nichts wissen, einigt man sich auf die Schnittmenge von alldem. Im ungünstigsten Fall landet man bei C, aber die Chance ist zumindest gegeben, dass man mehr als C benutzen kann.

Tim schrieb:

Außerdem vertrete ich die Meinung, dass eine Vielzahl an Sprachmöglichkeiten hinderlich sein kann.

Das solltest Du vielleicht begründen, ist für mich nicht so ersichtlich.

Tim schrieb:

Sieht man bereits hier: Es gibt Leute die argumentieren, dass man "in C++ auch C schreiben kann" und es gibt Leute die argumentieren, dass man die Komplexität von C++ dadurch meistern kann, dass man Grundlagen (low-level String-Handling, einfache Arrays, etc. pp.) erst gar nicht direkt lernt und gleich alles mit STL&Co erledigt.

Leute die argumentieren bestimmte Aspekte einer Sprache wegzulassen, haben einfach keine Ahnung. Selbstverständlich gehören nullterminierte char-Arrays und die dazugehörigen C-Funktionen genau so zu C++ dazu, wie std::string und die STL. Selbst wenn Du std::string nicht verwenden darfst oder willst, bietet dir C++ mehr Möglichkeiten, mit char-Arrays zu arbeiten (<algorithm> z.B.) als C.

Kurz gesagt: ich kann hier keinen Grund sehen, warum C vorteilhafter gegenüber C++ ein sollte.

[asc]

Tim schrieb:

...und es gibt Leute die argumentieren, dass man die Komplexität von C++ dadurch meistern kann, dass man Grundlagen (low-level String-Handling, einfache Arrays, etc. pp.) erst gar nicht direkt lernt und gleich alles mit STL&Co erledigt.

Ich kenne keinen der so argumentiert, sondern das man erst den einfachen Weg (z.B. std::string) gehen soll, und dann erst was sich dahinter verbirgt. Ich empfinde es als einfacher wenn man erst einmal ein wenig mit einfachen Programmen die Grundzüge [Schleifen, Ausgabe, Eingabe...] lernen kann, ohne gleich von Anfang an Zeigerarithmetik noch erklären zu müssen, bevor man die Stringmanipulation durchführen kann.

Ich drehe halt einfach die Reihenfolge um: Anfänger wollen meist Ergebnisse sehen, danach kann man noch genau erklären was sich dahinter verbirgt. Und ich behaupte auch das man die C-Spezifischen Bibliotheksteile als C++ Entwickler nicht zwangsweise lernen muss (oder nur zu einen kleinen Teil).

Um einen Videorekorder zu verwenden, schraube ich ihn auch nicht im Vorfeld auf...

[DEvent]

Mein "Problem" mit C++ ist, dass ich dafür keine Verwendung habe, es ist irgendwie obsolete. Für low-level kann man auch in C gut programmieren und den Code kapseln/abstrahieren. Ich habe z.B. eine Bibliothek für das Auslesen von Daten von einem an USB angeschlossenen Gerät geschrieben. Der Code sieht ca. so aus:

#ifdef LINUX
    RssconlinuxPortdata portdata = { { 0 } };
    strcpy(portdata.devicePath, "/dev/ttyUSB0\0");
    noiseread.portdata = &portdata;
    rssconlinuxSetupInterface(&noiseread);
#endif
    if (!noiseOpen(&noiseread))
        { error(&noiseread, "error by noiseOpen()...\n"); return 1; }
        if (!noiseStart(&noiseread))
            { errorclose(&noiseread, "error by noiseStart()...\n"); return 1; }
            NoiseData noisedata = { 0 };
            if (!noiseRead(&noiseread, &noisedata, 1))
                { errorclose(&noiseread, "error by noiseRead()...\n"); return 1; }
        noiseStop(&noiseread);
    noiseClose(&noiseread);

In C++ würde das vielleicht so aussehen:

#ifdef LINUX
    Rsscon rsscon = RssconLinux("/dev/ttyUSB0\0");
#endif
    Noiseread noiseread = Noiseread(rsscon);
    if (!noiseread.open()))
        { error(&noiseread, "error by noiseOpen()...\n"); return 1; }
    if (!noiseread.start())
            { errorclose(&noiseread, "error by noiseStart()...\n"); return 1; }
    NoiseData data;
    if (!noiseread.read(&data, 1))
                { errorclose(&noiseread, "error by noiseRead()...\n"); return 1; }
    noiseread.stop();
    noiseread.close();

Bitte wo hat mir jetzt die Verwendung von C++ Vorteile gebracht?

Nun zu hi-level, wie GUI, Server-Client, usw.
In C++ ist nichts Standard, nicht mal so was essentielles wie eine String-Klasse. Wieso nicht also Python, Ruby, Java oder C# nehmen, die alle mit einer sehr reichhaltigen Standard-Bibliothek kommen, einen GC haben und Exceptions gut unterstützen.

Dann die Compilierzeit. Die Zeit, die C++ Entwickler nur da sitzen und auf das Ende des Compilers warten, kann man auch besser nutzen. In Java kann ich Änderungen in unter 1 Sekunde kompilieren für 5k SLOC Java Klasse. Ich brauche nicht das gesamte Projekt neu zu übersetzen, wenn sich mal eine Interface einer Klasse ändert. Ein Projekt von 30k SLOC Java ist auch in unter 5 Sekunden komplett kompiliert.

Bibliothekenverwaltung ist in C++ auch aus dem letztem Jahrhundert. In Java kann ich jede Jar nehmen und in mein Projekt integrieren. In C++ muss ich entweder erst das Projekt übersetzen (und dafür brauche ich sämtliche Abhängigkeiten) oder hoffen das es für mein System, Architektur und Compiler(!) eine Bibliothek gibt.

[MasterK]

DEvent schrieb:

Bitte wo hat mir jetzt die Verwendung von C++ Vorteile gebracht?

Du stellst die falsche frage. Eine bessere frage wäre "Wieso erkenne ich die vorteile, die einem C++ bringen kann, nicht?"

Beim rest würde ich aber zustimmen, allerdings vergleichst du da ja nicht C++ mit C, sondern mit java, C# und python. Das sind aber andere baustellen.

[DEvent]

MasterK schrieb:

DEvent schrieb:

Bitte wo hat mir jetzt die Verwendung von C++ Vorteile gebracht?

Du stellst die falsche frage. Eine bessere frage wäre "Wieso erkenne ich die vorteile, die einem C++ bringen kann, nicht?"

Beim rest würde ich aber zustimmen, allerdings vergleichst du da ja nicht C++ mit C, sondern mit java, C# und python. Das sind aber andere baustellen.

Welche Vorteile würde mir den C++ bringen? Das ich die super STL verwenden kann? Danke, aber auf die ganzen Iteretoren, doppelt und dreifach, kann ich verzichten.

[Bashar]

Wenn du C++ so verstehst, wie in deinem Beispiel oben, dann bringt es dir natürlich nichts. Das ist natürlich auch typisch für C++-Basher, dass sie irgendwie denken, C++ wäre, wenn man C-Code nimmt und class davor schreibt.

[DEvent]

Bashar schrieb:

Wenn du C++ so verstehst, wie in deinem Beispiel oben, dann bringt es dir natürlich nichts. Das ist natürlich auch typisch für C++-Basher, dass sie irgendwie denken, C++ wäre, wenn man C-Code nimmt und class davor schreibt.

Klär mich auf. Talk is cheap, show me the code.

[Bashar]

fricky reloaded? Wenn du von Destruktoren und Exceptions noch nichts gehört hast, aber meinst, dich unbedingt zum Thema C vs. C++ äußern zu müssen, ist es an dir, dich (vorher!) über das Thema zu informieren. Stattdessen polterst du hier mit irgendwelchem Unsinn rum und verlangst dann aufgeklärt zu werden.

[MasterK]

DEvent schrieb:

Welche Vorteile würde mir den C++ bringen? Das ich die super STL verwenden kann? Danke, aber auf die ganzen Iteretoren, doppelt und dreifach, kann ich verzichten.

Man kann vorteile von C++ auch ohne die sogenannte STL geniessen. Ich persönlich mag die standardbibliothek von C++ überhaupt nicht und nutze die auch so gut wie gar nicht.
Du schreibst da oben ein dutzend zeilen code, und darunter den gleichen code, nur mit klassen. Das ist der einzige unterschied in deinem code. Und wenn das für dich der einzige unterschied zwischen C und C++ ist, dann hast du's wirklich nicht verstanden und solltest dich intensiver mit der materie beschäftigen.

Allein schon details wie diese hier

NoiseData data;
    if (!noiseread.read(&data, 1))

sind so typisches "C code in C++ gegossen". Wer C++ so programmiert, zeigt doch schon, dass er's nicht verstanden hat.

[DEvent]

Bashar schrieb:

fricky reloaded? Wenn du von Destruktoren und Exceptions noch nichts gehört hast, aber meinst, dich unbedingt zum Thema C vs. C++ äußern zu müssen, ist es an dir, dich (vorher!) über das Thema zu informieren. Stattdessen polterst du hier mit irgendwelchem Unsinn rum und verlangst dann aufgeklärt zu werden.

Das war klar, dass Exceptions vorgeschlagen werden. Tatsache it aber, Exceptions C++ sind extrem nutzlos, bis auf den kleinen Vorteil, dass man wenigstens so Fehler in Operatoren abfragen kann. Dann kommt noch der ganze bloat nur wenn man Exceptions einschaltet. Z.B. 10 bis 20% in wxWidgets.

[Bashar]

Tatsache ist das, sagst du. Soso.

[MasterK]

Und destruktoren? Unterschlägst du?

Dein C-Code ist btw scheisse... wenn noiseOpen funktioniert, noiseStart aber fehlschlägt, ruft niemand mehr noiseClose auf. Und das ist ja wohl wichtig, sonst würdest du's weiter unten nicht explizit aufrufen.
Mit einem vernünftigem try-catch-block und einem vernünftig implementierten desktruktor in Noiseread kein problem. Vor allem ohne dass man sich in lauter if-blöcke stürzen müsste.

[DEvent]

Zu den Destruktoren, du willst sicher die close() Funktion in den Destruktor packen? Was passiert aber, wenn sie Fehlschlägt? Ein Dtor kann keine Exceptions werfen, der Fehler wird für immer unentdeckt bleiben (es sei den ich Log das in eine Datei oder gebe was in der Konsole aus). In dem Fall eben ist das nicht so schlimm weil ich das Programm beende, aber das Gerät bleibt im Fehlerzustand und muss neu gestartet werden.