C++ und C, Unterschied

[hgfdasx]

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.

[gary1195]

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

[SeppJ]

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.

[Old Skool Progger]

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.

[Bitte ein Bit]

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.

[Bitte ein Bit]

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.

[Bashar]

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.

[K&R]

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?

[Nathan]

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.

[Old Skool Progger]

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

[Bitte ein Bit]

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.

[Nathan]

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

[SeppJ]

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.

[Wutz]

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

[Tyrdal]

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?

[Wutz]

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.

[Bashar]

Des einen Stack ist des anderen automatic storage duration.

[SeppJ]

Tyrdal schrieb:

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?

Auf die gleiche Art und Weise, wie du weißt, ob deine normalen Variablen auf den Stack passen: Du legst einfach keine riesengroßen Objekte auf den Stack und hoffst, das mit dieser Faustregel schon alles passen wird! Oder prüfst du vor jedem Funktionsaufruf, ob dieser nicht den Stack überlaufen lassen könnte?

Besser ist natürlich zu überlegen, ob du ein überhaupt ein VLA möchtest. Schließlich läuft obige Prüfung darauf hinaus, ob das Array größer oder kleiner wäre als das größte Array mit statischer Größe, das du noch guten Gewissens auf den Stack legen würdest. Warum dann nicht ein statisches Array dieser Größe nehmen?

[Bitte ein Bit]

#include <stdio.h>
#include <stdlib.h>

typedef struct
{
  char Name[256];
  char Vorname[256];
  int Alter;
} tPerson;

typedef struct
{
  tPerson Personen[32];
  int Anzahl;
} tHaus;

typedef struct
{
  tHaus Haus[50];
  int Anzahl;
} tStrasse;

int Test2(void)
{
  tStrasse S2;

  S2.Anzahl = 0;
  return 0;
}

int Test(int Size)
{
  tStrasse List[Size];

  //return Test2();
  return 0;
}

int main(int argc, char** argv)
{
  Test(1);
  return 0;
}

Mit Test(1) funktioniert es noch. Bei Test(2) kommt schon die Stack Overflow Fehlermeldung. Und dies ist kein untypisches Array!

Der Fehler ist sporadisch, da er abhängig von der aktuellen Stack Belegung ist und der Größe des Funktionsparameters Size!

Wie soll man solch ein Problem lösen?

Ein Compilerhersteller kann VLA auch im Heap (wird auch vom Standard nicht gekannt) anlegen und wäre immer noch standardkonform.

Wer macht das schon? Das Ganze endet doch dann in nicht portablen Code.

[SeppJ]

Bitte ein Bit schrieb:

Und dies ist kein untypisches Array!

Ähh, doch? Selbst ein Einzelobjekt mit einer sizeof wie tStrasse würdest du niemals in den automatischen Speicher stecken, geschweige denn ein Array davon anlegen.

P.S.: Für alle, die nicht rechnen möchten: sizeof(tStrasse) == 825804, falls sizeof(int)==4.