C/C++ Forum :: C vs. C++

minimaluser Mitglied 14:11:00 07.08.2002 Titel:

Hallo,

Es tut mir leid, wenn euch diese Frage irgendwie trifft (das ist wirklich nicht so gemeint);
grad hab ich (in bezug auf Programmieren eine völlige Niete) gelesen:
(http://www.research.att.com/~bs/bs_faq.html#diatribes -das ist von Stroustrup, dem Menschen der C++ erfunden hat)
"
C is better than C++ for small projects, right?

Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.
"

Stimmt das ?

THX
*sichimCforumganzunbeliebtmach;)*

Shade Of Mine Moderator 14:47:00 07.08.2002 Titel:

Mal ehrlich, was erwartest du von dem C++ Erfinder?

C++ ist nunmal der Nachfolger von C (und wie da Vinci schon sagte: "Arm ist der Schueler der seinen Lehrer nicht ueberfluegelt" - und arm ist C++ sicherlich nicht

)

Aber gerade bei kleinen Projekten denke ich, dass ich mehr Mehraufwand durch das Objekt Orientierte Design habe, als ich Nutzen daraus ziehe!

OK, jetzt kommt sicher das gegenargument: man muss in C++ ja nicht Objekt Orientiert Programmieren. Stimmt! Aber dann sehe ich es eher als C denn als C++ an.

Aber generell kann man sagen: C kann nichts was C++ nicht auch kann (logisch, denn C ist ja fast vollstaendig in C++ enthalten)

Allerdings kenne ich einen guten Grund, warum man C statt C++ einsetzen sollte: wenn man ein altes Projekt erweitern, ausbauen oder sonstwas muss, und dies ist in C geschrieben -> dann bleib bei C, denn nix ist schlimmer als ein C und C++ gemisch!

cLE Mitglied 14:54:00 07.08.2002 Titel:

Hi!

Zitat:

"
C is better than C++ for small projects, right?

Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.
"

Stimmt das ?

Meiner Meinung nach ist C++ immer C vorzuziehen.

C Programme sind (eigentlicht: waren) meistens kleiner und schneller als Objektorientierte C++ Programme. C ist auf PCs nicht mehr interessant, da die Geschwindigkeits differenzen unwesentlich sind. Wenn du allerdings für Mikrocontroller Programme schreiben willst, würde ich C benutzen, da du dann nicht den ganzen Overhead von C++ hast (auch auf den Arbeitsspeicher bezogen). Der entscheidenste Nachteil von C ist, dass es keine Objektorientierte Sprache ist.

[ Dieser Beitrag wurde am 07.08.2002 um 16:58 Uhr von cLE editiert. ]

Daniel E. Mitglied 15:17:00 07.08.2002 Titel:

Zitat:

Original erstellt von minimaluser:

"
C is better than C++ for small projects, right?

Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.
"

Mit der Argumentation würde vielleicht heute schon die ganze Welt in Programmiersprachen mit lesbarer Syntax programmieren ...

De facto gibt es aber vielleicht einen guten C++-Compiler der auf ebensovielen Plattformen läuft.

Shade Of Mine Moderator 15:54:00 07.08.2002 Titel:

Zitat:

Original erstellt von cLE:

C Programme sind (eigentlicht: waren) meistens kleiner und schneller als Objektorientierte C++ Programme.[...] den ganzen Overhead von C++ hast (auch auf den Arbeitsspeicher bezogen).

Wenn volkard das liest, bekommst du eine auf den Deckel...

cLE Mitglied 16:56:00 07.08.2002 Titel:

@Shade Of Mine: Möglich. Ich vermute einfach mal, da Volkard einer der C++ Mods ist, dass er in dieser Diskussion ganz eindeutig für C++ wäre (bin ich auch). Ich glaube meine Aussage oben war nicht eindeutig: Ich bezog mich mit dem ja, auf "Not in my opinion[...]". Also pro C++. In meinem Post steht auch, dass die Geschwindigkeitsvorteile von C gegenüber C++ auf PCs nicht relevant sind. Wenn ein Programm wegen seiner Objektorientierten Struktur langsamer als die Strukturierte Variante ist, stimmt etwas mit dem Design ganz und gar nicht.

[ Dieser Beitrag wurde am 07.08.2002 um 17:15 Uhr von cLE editiert. ]

Shade Of Mine Moderator 17:03:00 07.08.2002 Titel:

Zitat:

Original erstellt von cLE:
Wenn ein Programm wegen seiner Objektorientierten Struktur zu langsam ist, stimmt etwas mit dem Design ganz und gar nicht.

Besser das in
"Wenn ein Programm wegen seiner Objektorientierten Struktur langsamer als die Strukturierte Variante ist, stimmt etwas mit dem Design ganz und gar nicht."
aus. und alle sind happy ;)

Wenn du naemlich behauptest 'Abstraktion kostet Performance', dann bekommst du von HumeSikkins (dem naechsten C++ Mod) eine auf den Deckel

cLE Mitglied 17:14:00 07.08.2002 Titel:

Zitat:

Original erstellt von Shade Of Mine:
Besser das in
"Wenn ein Programm wegen seiner Objektorientierten Struktur langsamer als die Strukturierte Variante ist, stimmt etwas mit dem Design ganz und gar nicht."
aus. und alle sind happy ;)

Wenn du naemlich behauptest 'Abstraktion kostet Performance', dann bekommst du von HumeSikkins (dem naechsten C++ Mod) eine auf den Deckel

Teil eins stimme ich hundertprozentig zu.
Zu Teil zwei: Lies meinen Text. Dort steht

Zitat:

[...]dass die Geschwindigkeitsvorteile von C gegenüber C++ auf PCs nicht relevant sind

.

Shade Of Mine Moderator 17:19:00 07.08.2002 Titel:

und ich bleib trotzdem dabei.

Ein gutes C++ Programm ist nicht langsamer als sein C-Kollege.
Voraussetzung ist natuerlich ein gleichwertiger Compiler, was im embedded Bereich vermutlich nicht immer gegeben ist...

cLE Mitglied 17:33:00 07.08.2002 Titel:

Zitat:

Ein gutes C++ Programm ist nicht langsamer als sein C-Kollege.

Hab ich dass nicht so ähnlich geschrieben (für PCs)?

Zitat:

Voraussetzung ist natuerlich ein gleichwertiger Compiler, was im embedded Bereich vermutlich nicht immer gegeben ist...

Für sehr viele Controller steht gcc zur Verfügung. Das stellt also kein Problem dar.

Also: C++ hat keine messbaren Nachteile (z.B. wegen virtual Funktionen o.ä.) bei PCs, Konsolen u.ä., aber bei Controllern mit 8Kb Rom, 2Kb Ram und 8Mhz (teilweise noch weniger) wirds eng im Vergleich zu C.

Shade Of Mine Moderator 17:53:00 07.08.2002 Titel:

wusstest du, dass virtual Funktionen (also eigentlich die vtable) schneller sind als das vergleichbare switch (also eigentlich die Sprungtabelle)?

HumeSikkins Mitglied 17:58:00 07.08.2002 Titel:

Hallo,
die Frage ist doch, wie Stroustrup die Aussage verstanden wissen will.

In einer perfekten Welt in der alle C++ Compiler toll optimieren und alle Bibliotheken gut geschrieben sind und in der es nur gute C++ Programmierer gibt, die nicht ständig irgendwo ausversehen temporäre Objekte erzeugen (und davon kann es in C++ ganz schnell ganz viele geben) und nicht völlig überflüssige Vererbung einsetzen und klobige Designs fabrizieren, hat C wahrscheinlich wirklich keine Vorteile gegenüber C++. Schließlich gibt es keinen sprachbedingten Performanceunterschied und C++ bietet zusätzlich viel reichhaltigere Sprackkonstrukte und vielmehr Möglichkeiten Fehler bereits zur Compilezeit zu entdecken.

Da die Welt aber nicht perfekt ist und da es schlechte C++ Compiler, schlechte C++ Bibliotheken und schlechte C++ Programmierer gibt und da es gleichzeitig sehr gute C Compiler, sehr gute C Bibliotheken und sehr gute C Programmierer gibt, existieren sicher auch Situationen/Projekte wo C eindeutig im Vorteil ist.

Man sollte sich nur mit beiden Sprachen sehr gut auskennen bevor man eine Entscheidung trifft. Die Sprachauswahl sollte schließlich keine Bauchauswahl sein. Auch wenn das einige hier im Forum anders sehen :)

[ Dieser Beitrag wurde am 07.08.2002 um 17:59 Uhr von HumeSikkins editiert. ]

cLE Mitglied 18:17:00 07.08.2002 Titel:

Zitat:

wusstest du, dass virtual Funktionen (also eigentlich die vtable) schneller sind als das vergleichbare switch (also eigentlich die Sprungtabelle)?

Jepp:
vtable bedeutet eine Zeigeroperationen (indizieren des this-Zeigers für die entsprechende Funktion der Klasse), bevor die Funktionsadresse bekannt ist.
switch ist einfach nur furchtbar langsam, du könntest auch if - else if ... schreiben. Bei n-cases gibts halt bis zu n Vergleiche wenn man Pech hat. switch sollte möglichst vermieden werden.

volkard Moderator 19:50:00 07.08.2002 Titel:

Zitat:

Original erstellt von Shade Of Mine:
wusstest du, dass virtual Funktionen (also eigentlich die vtable) schneller sind als das vergleichbare switch (also eigentlich die Sprungtabelle)?

Ist mir neu.
begründung:
switch ist dazu da, ne Sprongtabelle zu bauen!
Am nehme nur eben als Werte welche, die schön als Arrayindizes passen.
Also

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	enum {HUND,KATZE,MAUS,DELFIN}; ... switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: fehler(); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	enum {HUND,KATZE,MAUS,DELFIN}; ... switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: fehler(); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	enum {HUND,KATZE,MAUS,DELFIN}; ... switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: fehler(); }

so, hier haben wir erzeugt:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	if(unsigned(typ)<=3) jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; else fehler; ende:

C/C++ Code:
1 2 3 4 5 6 7 8 9	if(unsigned(typ)<=3) jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; else fehler; ende:

C/C++ Code:
1 2 3 4 5 6 7 8 9	if(unsigned(typ)<=3) jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; else fehler; ende:

Und siehe da, es hat einen Vergleiche gekostet und einen Tabellezugriff.
Keine if-Orgie.
Auf manchen Compiler kann man den Vergleich noch weghauen (für mutige).

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	1 2 3 4 5 6 7 8 9 10 11	enum {HUND,KATZE,MAUS,DELFIN}; ... assert(unsigned(typ)<=DELFIN); switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: __assume(0);//code can not be reached }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	enum {HUND,KATZE,MAUS,DELFIN}; ... assert(unsigned(typ)<=DELFIN); switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: __assume(0);//code can not be reached }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	enum {HUND,KATZE,MAUS,DELFIN}; ... assert(unsigned(typ)<=DELFIN); switch(type) { case HUND: hund(this);break; case KATZE: katze(this);break; case MAUS: maus(this);break; case DELFIN: delfin(this);break; default: __assume(0);//code can not be reached }

und er macht draus:

C/C++ Code:
jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; ende:

C/C++ Code:
jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; ende:

C/C++ Code:
jumpto tabelle[typ]; /hier ist tab[0]/hund();goto ende; /hier ist tab[1]/katze();goto ende; /hier ist tab[2]/maus();goto ende; /hier ist tab[3]/delfin();goto ende; ende:

Und jetzt kommt das Leckerli: hund(), katze(), maus() und delfin() können inline sein!
Und noch eins: Ich kann mit sizeof(typ) aussuchen, muß nicht immer ein Zeiger sein.
Und noch eins, ich kann mir aussuchen, wo im Objekt typ steht, evtl bei sowas wie

C/C++ Code:
struct Message { int timeToArrive; int typ; };

C/C++ Code:
struct Message { int timeToArrive; int typ; };

C/C++ Code:
struct Message { int timeToArrive; int typ; };

wo ich die Messages alle in nem heap halten will, kanns ja sein, daß der Zugriff aufs erste Member schneller ist.
Denn
int getTyp(Message* m)
wird zu
return *(int*)m;
statt
return *((int*)m+1);

Ist zwar nicht gerade bedeutend, aber ich halte es für falsch, zu sagen, vptrs seien einfach schneller als switch.

volkard Moderator 19:58:00 07.08.2002 Titel:

Zitat:

Original erstellt von Shade Of Mine:
Aber gerade bei kleinen Projekten denke ich, dass ich mehr Mehraufwand durch das Objekt Orientierte Design habe, als ich Nutzen daraus ziehe!

Tip:
Dies ist kein gutes C++-Programm:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	class Quadrat { private: int i_; public: Quadrat(int i) :i_(i) { } void berechne() { i_=i_; } int* ergebnis() { return i_; } }; ... int x; Quadrat q(x); q.berechne(); x=q.ergebnis();

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	class Quadrat { private: int i_; public: Quadrat(int i) :i_(i) { } void berechne() { i_=i_; } int* ergebnis() { return i_; } }; ... int x; Quadrat q(x); q.berechne(); x=q.ergebnis();

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	class Quadrat { private: int i_; public: Quadrat(int i) :i_(i) { } void berechne() { i_=i_; } int* ergebnis() { return i_; } }; ... int x; Quadrat q(x); q.berechne(); x=q.ergebnis();

Man meide in C++ overengeneering.

C/C++ Code:
int quadrat(int i) { return ii;//so einfach ist C++* }

C/C++ Code:
int quadrat(int i) { return ii;//so einfach ist C++* }

C/C++ Code:
int quadrat(int i) { return ii;//so einfach ist C++* }

Zitat:

OK, jetzt kommt sicher das gegenargument: man muss in C++ ja nicht Objekt Orientiert Programmieren. Stimmt! Aber dann sehe ich es eher als C denn als C++ an.

Es gibt mehr an C++ als virtuelle Funktionen. Und feine C-Programme sind meist auch objektorientiert.

Zitat:

Aber generell kann man sagen: C kann nichts was C++ nicht auch kann (logisch, denn C ist ja fast vollstaendig in C++ enthalten)

Ganz wichtiger Punkt. Das impliziert, daß man in C++ stets und jederzeit, sobald eine Lösung unter Verzicht von aufgeblasenen C++-Mitteln, also in C, schneller wäre, es machen kann, wie man es in C machen würde. Ist das nicht total Klasse?
Daher kann ich auch kaum nachvollziehen, wo C++ langsamer sein könnte.
Außer natürlich, weil die <iostream> so fett ist und ein dutzend von kilobytes Code macht. die wolllen geladen werden und fressen in der tat mehr ram als printf. aber naja, theoretisch kann cout schneller sein als printf, weil die typen bekannt sind und deshalb der formastring nicht geparsed werden muß. isses noch nicht, soweit ich feststellen kann.

[ Dieser Beitrag wurde am 07.08.2002 um 20:08 Uhr von volkard editiert. ]

Daniel E. Mitglied 21:52:00 07.08.2002 Titel:

Zitat:

Original erstellt von volkard:
isses noch nicht, soweit ich feststellen kann.

Teste doch mal mit `std::cout.sync_with_stdio(false)' in der ersten Zeile. Meine Messungen mit der GCC-Reihe zeigte da Vorteile für `std::cout'.

Helium Mitglied 17:58:00 09.08.2002 Titel:

Hier wurde der Speicheroverhead angesprochen. Um sowas zu vermeiden kann man Dinge wie einen pool verwenden. Aber malloc hat das selbe problem wie new und ist somit nicht C++-spezifisch.

virtuell Realisticer Mitglied 19:41:00 11.08.2002 Titel:

Kann man nicht einen Thread wie "C vs. C++" in die FAQ aufnehmen?

Dann kann man immer, wenn jemand sowas anfaengt auf die FAQ ver-
weisen und erspart sich den Glaubenskrieg!

mfg
v R