Unterschied c c++ c#

[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.

[MasterK]

Wie behandelst du denn in deinem C code einen fehler in der close-funktion?

[DEvent]

MasterK schrieb:

Wie behandelst du denn in deinem C code einen fehler in der close-funktion?

Die close() Funktion liefert einen Fehlercode, was ein Dtor in C++ nicht kann. Trotz aller C++ Magie, wie RAII, brauchst du für externe Ressourcen eine open() und eine close() Funktion und Exceptions in C++ sind nicht besser als if-Blöcke in C.

[Clown]

DEvent schrieb:

Die close() Funktion liefert einen Fehlercode, ...

Und was machst du dann, wenn die Funktion fehlschlägt? Wie willst du auf so einen Fehler reagieren?

DEvent schrieb:

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.

DEvent schrieb:

... und Exceptions in C++ sind nicht besser als if-Blöcke in C.

Boah, was für eine konkrete Argumentation. Deine nicht vorhanden Argumente überzeugen micht völlig. Naja, um ehrlich zu sein, habe ich eher das Gefühl, dass du einfach Exceptions und C++ nicht verstanden hast.

Wo haben wir nochmals *in seiner Clownkiste rumwühlt* ... aja, hier:
Exception Handling
Modernes Exception-Handling Teil 1
Modernes Exception-Handling Teil 2

So und jetzt geht der DEvent schön lesen, ja? Und kommt dann wieder mit richtigen Argumenten, statt nur irgendwelchen Parolen, welche nichts weiteres als heisse Luft sind.

[Gast]

Bashar schrieb:

fricky reloaded?

Schon wieder einer, den Du verdächtigst diese "fricky" zu sein? Wer ist das überhaupt?

PS: Ich warte immer noch auf glaubhafte Argumente pro-C und gegen C++.

[DEvent]

Clown schrieb:

DEvent schrieb:

Die close() Funktion liefert einen Fehlercode, ...

Und was machst du dann, wenn die Funktion fehlschlägt? Wie willst du auf so einen Fehler reagieren?

DEvent schrieb:

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.

DEvent schrieb:

... und Exceptions in C++ sind nicht besser als if-Blöcke in C.

Boah, was für eine konkrete Argumentation. Deine nicht vorhanden Argumente überzeugen micht völlig. Naja, um ehrlich zu sein, habe ich eher das Gefühl, dass du einfach Exceptions und C++ nicht verstanden hast.

Wo haben wir nochmals *in seiner Clownkiste rumwühlt* ... aja, hier:
Exception Handling
Modernes Exception-Handling Teil 1
Modernes Exception-Handling Teil 2

So und jetzt geht der DEvent schön lesen, ja? Und kommt dann wieder mit richtigen Argumenten, statt nur irgendwelchen Parolen, welche nichts weiteres als heisse Luft sind.

Genau. Seitenlange Tutorials für so was simples wie Exceptions. Man braucht schon ein Diplomabschluss in C++tologie um eine exceptionsichere Stack-Klasse zu schreiben.
Wenn ihr doch alles besser wisst, dann schreibt mir unwissenden doch ein Beispiel. Ich habe diesen Code hier in C, wie würdet ihr es in C++ lösen und wo sind die Vorteile:

#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"); goto close; }
            NoiseData noisedata = { 0 };
            if (!noiseRead(&noiseread, &noisedata, 1))
                { errorclose(&noiseread, "error by noiseRead()...\n"); goto stop; }

stop:
    noiseStop(&noiseread);
close:
    noiseClose(&noiseread);

[krümelkacker]

DEvent schrieb:

Mein "Problem" mit C++ ist, dass ich dafür keine Verwendung habe,

Nun, wenn ich einen Nagel reinhauen will, nehme ich auch einen Hammer und keinen Schraubenzieher. So gesehen, ist bis hier noch nichts anzukreiden.

DEvent schrieb:

es ist irgendwie obsolete. Für low-level kann man auch in C gut programmieren und den Code kapseln/abstrahieren.

Ok, das siehst Du so. Andere Teilen diese Sicht anscheinend nicht.

DEvent schrieb:

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

Das kann man bei diesem kleinen Beispiel schlecht beurteilen. Es kann sein, dass bei dem Problem, was Du gelöst hast, die "optimale" C++ Lösung sehr ähnlich aussieht. Angenommen, das wäre so. Das hieße jetzt nicht, dass es nicht andere Problemstellungen gibt, die sich mit C++ Sprachmitteln viel eleganter lösen lassen. Andere Problemstellungen kann ich vielleicht mit einem Schraubenzieher viel eleganter lösen als nur mit einem Hammer, um bei dem Bild der Werkzeugkiste zu bleiben. Ich denke nicht, dass hier jemand behauptet hat, C++ sei die beste Sprache für jeden Job. Wenn Du für viele verschiedene, andere Problemstellungen immer noch C vorziehen würdest, dann liegt das wahrscheinlich an mindestens einem der folgenden Gründe:
1. Du betrachtest nur einen sehr speziellen, Dich betreffenden Problembereich, in denen "ein Hammer vollkommen ausreicht und jedes beliebige andere Werkzeug keine Erleichterung darstellt".
2. Du kennst die Sprache C++ nicht gut genug ("Du hältst einen Schraubenzieher für einen komisch aussehenden Hammer")

DEvent schrieb:

Nun zu hi-level, wie GUI, Server-Client, usw.
In C++ ist nichts Standard, nicht mal so was essentielles wie eine String-Klasse.

Was ist denn an std::string "nicht Standard"?

DEvent schrieb:

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.

Nun, das ist eine komplett andere "Werkzeugkiste", die Du da aufmachst. Ich denke, C++ hat seine Existenzberechtigung. Es schafft low- und high-level Programmierung ohne Overhead ("zero overhead principle") zu kombinieren und ist damit auch bequem in "eingeschränkten Umgebungen" nutzbar.

DEvent schrieb:

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.

Wenn sich da etwes an einer Schnittstelle ändert, müsste man dann nicht auch den Code anpassen, der diese Schnittstelle benutzt? Und warum sollte man anderen Code neu kompilieren, der überhaupt nichts von dieser Schnittstelle weiß? Ich kenne die Argumentation etwas anders. Da regen sich Leute auf, weil sie nur Implementierungsdetails ändern und einiges neu kompilieren müssen -- zB wenn sie private Objekt-Elemente hinzufügen/verändern/entfernen und dies natürlich im "Header verraten". Nun, in C und C++ hast Du die Wahl. Entweder verrätst Du, wie ein Objekt der Klasse aufgebaut ist (im Header). Das erlaubt Dir das Einbetten dieser Objekte in andere oder das Anlegen auf dem Stack. Oder, Du versteckst Implementierungsdetails ("pimpl", "compiler firewall idiom"). Dann beschränkst Du Dich aber auch auf dynamisches Anlegen/Löschen und Zugriff über ein "Handle" (zB Zeiger) und Änderungen an der Implementierung erfordern kein Neukompilieren der Übersetzungseinheiten, die nur einen Header einbinden, welcher keine Implementierungsdetails verrät. In Java kannst Du Dir das nicht aussuchen. Dort gibt es nur "Handles" (auch bekannt unter "Referenzen").

DEvent schrieb:

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.

Nun, das ist prinzipiell keine Einschränkung, die durch die Sprache selbst gemacht wird. C++ standardisiert eben nur die Sprache an sich + Standardbibliothek und nicht, wie das auszusehen hat, was der Compiler ausspuckt und entgegennehmen können muss bzgl Bibliotheken. Daher ist diese Sache "implementierungsabhängig". Man sollte sich jedenfalls mal mit dem einen oder anderen Build-System beschäftigen, welches systemspezifische Dinge idealerweise abstrahiert.

Kann das sein, dass Du nur Java und C kennst und glaubst, etwas über C++ zu wissen? Wie viele Erfahrungen hast Du mit C++ gemacht? Wie lange hast Du C++ programmiert? Welche Bücher hast Du zu C++ gelesen?