C++ und C, Unterschied



  • Hallo,

    ich habe jetzt unterschiedlichstes über C und C++ über Foren, Kollegen und Freunde erfahren.
    Kann mir das bitte jemand einmal genau aufdröseln, was man jetzt wie machen kann, wie die Sprachen zusammenhängen etc.?

    Das wäre sehr nett.

    Danke!

    Player894 (diesmal der echte...)


  • Mod

    Denk am besten, als wären es zwei verschiedene Sprachen, mit sehr ähnlicher Syntax. Geschichte und Hintergründe entnimmst du am besten Wikipedia.

    C++ kann in jeder Hinsicht mehr als C, das war gerade der Hauptgrund der Entwicklung. Was die Sprache auch sehr viel komplexer zu Erlernen macht. C kennt in erster Linie bloß nutzerdefinierte Datentypen und Funktionen als Abstraktionsmittel. Höhere Abstraktionsmethoden wie Objektorientierung oder typunabhängige Programmierung muss man relativ mühsam (und da einem der Compiler nicht mehr so gut helfen kann: fehleranfällig) selber umsetzen.

    C++ kann darüber hinaus von Haus aus Objektorientierung über Klassen und typunabhängige Programmierung über Templates. Und noch ein paar andere, aber dies sind die beiden wichtigsten Features. Dabei ist jedoch erhalten geblieben, dass C++, wie C, höchst portabel ist und dem Programmierer fast keine versteckten Zusatzkosten unterschiebt, daher auch sehr schnell ist (wenn der Programmierer gut ist).

    Theoretisch enthält C++ im Kern auch C. Das liegt zum einen an der gleichartigen Syntax, zum anderen ist die gesamte C-Standardbibliothek in C++ verfügbar. C++ hat jedoch seine eigene (ein wenig umfangreichere) Standardbibliothek, die ziemlich starken Gebrauch von Klassen und Templates macht und größtenteils total inkompatibel mit der C-Standardbibliothek ist, weshalb man die Benutzung nicht mischen sollten. Es ist jedoch möglich, einfache C-Programme mit einem C++-Compiler zu übersetzen. Bei komplexeren Programmen wird's schon kritisch, da muss man eventuell ein paar Sachen anpassen, denn so wirklich 100% ist C nicht in C++ enthalten. Seit den späten 90er entwickeln sich die Sprachen immer weiter auseinander. Wie schon gesagt: Behandele sie wie unterschiedliche Sprachen.

    Zwei (übertriebene) Beispielprogramme:
    http://www.99-bottles-of-beer.net/language-c-116.html
    http://www.99-bottles-of-beer.net/language-c++-111.html



  • Der Unterschied: C ist älter und sozusagen eine Teilmenge von C++, d.h. C-Code kannst du mit einem C++-Compiler fast immer ohne Änderungen übersetzen, aber umgekehrt nicht. C++ enthält viel mehr Sprachmittel als C und daher lohnt es sich eigentlich immer (außer, du hast irgend eine exotische Plattform ohne C++-Compiler o.ä.), C++ und nicht C zu verwenden.

    Einige dieser C++-Sprachmittel sind z.B. Klassen/Objektorientierung, templates, Funktions- und Operatorüberladung und Exceptions. Darüber hinaus gibt es natürlich auch dementsprechend noch zusätzliche Library-Funktionalität.

    Nur weil man C-Code in C++ schreiben kann, sollte man dies nicht tun!



  • Wie kann man denn die C-Standardbibliothek in C++ benutzen, wie geht das überhaupt?

    Ich meine, wenn der Quellcode übersetzt wird, übersetzt der Compiler die C-Standardbibliothek nach C++ hin, oder liegt die cstdlib in kompilierter Form vor?



  • Nein, da der C-Code auch in C++ funktioniert, kann die C-Standardbibliothek auch vom C++-Compiler übersetzt werden. Die Standardbibliothek liegt deswegen aber wie die meisten Bibliotheken (bis auf die Deklarationen) in der Praxis in kompilierter Form vor.



  • SeppJ schrieb:

    C++ kann in jeder Hinsicht mehr als C

    Wie sieht es aus mit
    - restrict
    - VLA
    - flexible array members

    Besonders die ersten beiden erlauben einiges mehr an Performance in C als in C++.

    Das standardisierte ABI zähle ich mal nicht als Sprachfeature.



  • wxSkip schrieb:

    Nein, da der C-Code auch in C++ funktioniert, kann die C-Standardbibliothek auch vom C++-Compiler übersetzt werden.

    Nein das stimmt so nicht, du kannst C Code nicht einfach mit einem C++ Compiler übersetzten, dafür sind die Sprachen zu unterschiedlich.
    Die libc wurde mit einem C Compiler übersetzt und C++ hat Header für die C stdlib zur verfügung (mit geänderten namen: stdlib.h -> cstdlib, assert.h -> cassert usw.) oder siehe nächster Satz.
    Da in C++ die Regeln für die Implementierung der enthaltenen "C stdlib" etwas anders sind als in C (zB müssen Funktionen anstatt von Makros verwendet werden), kann es durchaus sein, dass Teile oder die gesamte "C stdlib" in C++ geschrieben werden.

    Allgemein im Bezug auf C-lib in C++: C++ hat hier das extern "C" Sprachmittel, mit dem Funktionen als C-Funktionen deklariert werden. Dadurch kann man C bibliotheken einfach von C++ aus benutzen in dem man schreibt,

    extern "C" { #include "header.h"}
    

    und natürlich die Bibliothek dazulinkt

    einige header Dateien enthalten bereits

    #ifdef __cplusplus
    extern "C" {
    #endif
    Deklarationen
    #ifdef __cplusplus
    }
    #endif
    

  • Mod

    hgfdasx schrieb:

    SeppJ schrieb:

    C++ kann in jeder Hinsicht mehr als C

    Wie sieht es aus mit
    - restrict
    - VLA
    - flexible array members

    Ich wusste, als ich es schrieb, dass da schon wieder so ein Klugscheißer kommt, der irgendwelche obskuren Sprachfeatures nennen wird, die zwar kein Mensch benutzt (VLAs? Wirklich? Das ist dein Beispiel? Die sind in C11 sogar wieder zu einem optionalen Feature herabgestuft worden, weil sie doof sind.), aber mit denen sich eventuelle Beispiele künstlich konstruieren lassen. Kann man denn in diesem Forum nie eine Aussage treffen, die für 99.9999% aller Fälle richtig ist, ohne 5 Seiten Disclaimer drunter zu schreiben, was in den anderen 0.0001% sein könnte? 😡

    Aber schön 🙄 :
    VLAs: Siehe oben.
    Restrict: Brauchste in C++ nicht, weil du in C++ praktisch niemals Code schreiben würdest, der Aliasingprobleme hat. Das ist ein typisches C-Problem, eben wegen der Beschränkungen von C.
    FAM: Siehe VLAs.

    Zusammenfassung: Seit der Auseinanderentwicklung von C und C++, gab es ein paar Features in C, die kaum jemand benutzt; im Nachhinein als eher schlechte Idee gelten; man in C++ gar nicht braucht; die ein großer, bekannter Compiler für C nicht unterstützt; und die ein anderer großer, bekannter Compiler auch für C++ unterstützt. Aber technisch gesehen gibt es in C ein paar wenige Sachen, die man in C++ nicht machen kann. 🙄



  • Player894 schrieb:

    Hallo,

    ich habe jetzt unterschiedlichstes über C und C++ über Foren, Kollegen und Freunde erfahren.
    Kann mir das bitte jemand einmal genau aufdröseln, was man jetzt wie machen kann, wie die Sprachen zusammenhängen etc.?

    C++ ist C mit Klassen.

    Viel mehr ist da nicht dahinter.



  • flexible array members

    Welch fehleranfälliges Konstrukt...

    Solch ein Konstrukt ist doch die Vorstufe zum Saustall. Wer allokiert den Speicher? Ist überhaupt Speicher allokiert worden? Wer räumt den Speicher wieder auf? Wann darf ich sizeof() aufrufen? Darf ich solche Elemente kopieren, ohne ein Speicherloch zu riskieren?

    ----

    C++ ist für meinen Geschmack eine Sprache auf einem anderen Abstraktionsniveau. In C ist das Abstraktionsniveau niedrig. Man befasst sich schnell mit Speicherverwaltung (siehe Fragen oben). In C++ kümmert man sich darum meist wenig, denn mit ein wenig Sorgfalt lassen sich in C++ viele typische C Fehler vermeiden.

    C++ gibt aber dem Benutzer viele Hilfsmittel in die Hand. Und die müssen halt erlernt werden. Mit C++ kann man sich genussvoller ins Bein schießen als mit C.



  • VLA hat einen massiven Nachteil:

    Es liegt auf dem Stack. Und da C Datenstruktuen nicht dazu neigen rank und schlank zu sein, frisst dies schnell den Stack weg, s.d. das System je nach Lust und Laune sich verabschiedet.



  • Bitte ein Bit schrieb:

    flexible array members

    Welch fehleranfälliges Konstrukt...

    Wird aber anscheinend gebraucht. Früher hat man dazu ein Array der Größe 0 ans Ende der Struktur gepackt.

    VLA hat einen massiven Nachteil:

    Es liegt auf dem Stack.

    Glückwunsch zu deinem trockenen Humor.



  • Old Skool Progger schrieb:

    Player894 schrieb:

    Hallo,

    ich habe jetzt unterschiedlichstes über C und C++ über Foren, Kollegen und Freunde erfahren.
    Kann mir das bitte jemand einmal genau aufdröseln, was man jetzt wie machen kann, wie die Sprachen zusammenhängen etc.?

    C++ ist C mit Klassen.

    Viel mehr ist da nicht dahinter.

    😮
    Und Metaprogrammierung mit Templates etc. lässt du einfach mal weg? 👎

    Bitte ein Bit schrieb:

    VLA hat einen massiven Nachteil:

    Es liegt auf dem Stack. Und da C Datenstruktuen nicht dazu neigen rank und schlank zu sein, frisst dies schnell den Stack weg, s.d. das System je nach Lust und Laune sich verabschiedet.

    Das ist jetzt nicht dein ernst, oder?



  • SeppJ schrieb:

    Zwei (übertriebene) Beispielprogramme:
    http://www.99-bottles-of-beer.net/language-c-116.html
    http://www.99-bottles-of-beer.net/language-c++-111.html

    SeppJ, ich bin enttäuscht: Da gibt es so schöne C++ Beispiele, wie das oder das. :p

    @Old Skool Progger: Herzlichen Glückwunsch, du hast C++ verstanden.



  • Nathan schrieb:

    @Old Skool Progger: Herzlichen Glückwunsch, du hast C++ verstanden.

    Klar habe ich das, nur wollte ich meinen Spaß haben und ihr habt angebissen. 😃 :p



  • K&R schrieb:

    Das ist jetzt nicht dein ernst, oder?

    Bedingt. Es ist doch so eine typische Sache das man unter C alles selbst machen muss. Und selbst bei einigen schlechten C Compilern erlebt dass man die Optimierung auch in die Hand nehmen muss, da der Code fast eins zu eins in Assembly umsetzt wird.

    Und da habe ich den gleichen Schnellschuss gezogen...

    Wer erwartet denn hinter VLA eine ausgeklügelte Speicherverwaltung? Ich nicht. 😞



  • Old Skool Progger schrieb:

    Nathan schrieb:

    @Old Skool Progger: Herzlichen Glückwunsch, du hast C++ verstanden.

    Klar habe ich das, nur wollte ich meinen Spaß haben und ihr habt angebissen. 😃 :p

    Verdammt, ich hab mir noch sowas gedacht... 😡 😉


  • Mod

    Bitte ein Bit schrieb:

    K&R schrieb:

    Das ist jetzt nicht dein ernst, oder?

    Bedingt. Es ist doch so eine typische Sache das man unter C alles selbst machen muss. Und selbst bei einigen schlechten C Compilern erlebt dass man die Optimierung auch in die Hand nehmen muss, da der Code fast eins zu eins in Assembly umsetzt wird.

    Und da habe ich den gleichen Schnellschuss gezogen...

    Wer erwartet denn hinter VLA eine ausgeklügelte Speicherverwaltung? Ich nicht. 😞

    Ich glaube, du verstehst nicht: Der Vorteil von VLAs ist, dass sie auf dem Stack liegen. Das man nicht ungeprüft riesige Arrays auf den Stack legen sollte ist Aufgabe des Programmierers. Genau wie dieser auch alles andere vermeiden muss, was man so falsch machen könnte. Richtiges Programmieren eben.



  • SeppJ schrieb:

    (VLAs? Wirklich? Das ist dein Beispiel? Die sind in C11 sogar wieder zu einem optionalen Feature herabgestuft worden, weil sie doof sind.),

    Ich glaube nicht an diesen Erkenntnisgewinn in der WG14, ich tippe auf einen unüberlegten Schnellschuss in dieser Truppe aufgrund Einflüsterungen Einzelner, genau wie damals, als sie sich in C99 das Zeugs überhaupt ausgedacht haben.
    Curacao aus Austragungsort solcher Diskussionen+Beschlussfassungen auszuwählen legt per se schon eine gewisse Naivität für Ergebnisse solcher "Konferenzen" nahe.
    http://www.open-std.org/jtc1/sc22/wg14/www/documents



  • SeppJ schrieb:

    Das man nicht ungeprüft riesige Arrays auf den Stack legen sollte ist Aufgabe des Programmierers.

    Und wie prüfe ich, ob genug Platz auf dem Stack ist?



  • Bitte ein Bit schrieb:

    VLA hat einen massiven Nachteil:
    Es liegt auf dem Stack.

    SeppJ schrieb:

    Der Vorteil von VLAs ist, dass sie auf dem Stack liegen.

    VLA sind ein einziger Nachteil.
    Der Standard kennt überhaupt keinen Stack, demzufolge schreibt er sowas wie auch alle anderen gern in diesem Zusammenhang genannten Weisheiten bzgl. Implementierungen nicht vor.
    Ein Compilerhersteller kann VLA auch im Heap (wird auch vom Standard nicht gekannt) anlegen und wäre immer noch standardkonform.


Anmelden zum Antworten