www.mikrocontroller.net

Forum: PC-Programmierung ist C++ langsamer als C?


Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit C++ ist es ja möglich durch wenige Funktionsaufrufe einen großen 
Teil an Rechenarbeit zu verrichten, wofür in C mehrere Funktionsaufrufe 
nötig wären.

Sicherlich werden in den C++Bibliotheken mehrere Abfragen ausgeführt, um 
zu testen ob die übergebenen Argumente richtig sind, bzw. um zu testen 
was mit ihnen geschehen soll (zB bei überladenden Methoden). Im reinen 
C-Code würde man dies wohl eher versuchen auszuschließen.

Meine (eine reine Verständnissfrage) Frage wäre nun ob ihr glaubt, dass 
C++Code deshalb vielleicht langsamer in der Ausführung sein könnte?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Wurst wrote:
> Hallo,
>
> mit C++ ist es ja möglich durch wenige Funktionsaufrufe einen großen
> Teil an Rechenarbeit zu verrichten, wofür in C mehrere Funktionsaufrufe
> nötig wären.
>
> Sicherlich werden in den C++Bibliotheken mehrere Abfragen ausgeführt, um
> zu testen ob die übergebenen Argumente richtig sind, bzw. um zu testen
> was mit ihnen geschehen soll (zB bei überladenden Methoden). Im reinen
> C-Code würde man dies wohl eher versuchen auszuschließen.
>
> Meine (eine reine Verständnissfrage) Frage wäre nun ob ihr glaubt, dass
> C++Code deshalb vielleicht langsamer in der Ausführung sein könnte?

Die Frage stellt sich so nicht wirklich, denn du vergleichst Äpfel mit 
Birnen. Bei funktional identischen Programmen ist das was ein C++ 
Compiler (mit Optimierungen) produziert normalerweise in nichts 
langsamer als das was du in C produzierst.
Funktional identisch heist aber auch: Das C Programm, welches du 
schreibst, muss auch in Fehlerfällen sauber arbeiten. Und genau da liegt 
normalerweise das Problem. Während in C++ die Objekte normalerweise auf 
sich selbst aufpassen und Fehlerfälle korrekt handhaben, wird das in C 
gerne 'unter den Tisch gekehrt und auf später (=nie) verschoben'.

Tatsächlich ist es oft so, dass der C++ Code für den Programmierer oft 
kürzer ist als vermeintlich äquivalenter C-Code, dieser C++ Code 
allerdings sich beim compilieren etwas aufbläht, weil aus den einzelnen 
Klassen noch Fehlerfallprüfung dazu kommt. Tatsächlich äquivalenter 
C-Code, der auch diese Fehlerfälle korrekt handhabt ist hingegen 
meistens wesentlich länger. Zur Laufzeit kommt dann aber dank dem 
Optimizer etwas ziemlich gleichwertiges raus. Manchmal ist der C++ Code 
einen Tick schneller, manchmal der C-Code.

Beiden Sprachen gemeinsam ist hingegen der philosophische Ansatz: You 
don't pay for what you don't ask for.

> Sicherlich werden in den C++Bibliotheken mehrere Abfragen ausgeführt, um
> zu testen ob die übergebenen Argumente richtig sind, bzw. um zu testen
> was mit ihnen geschehen soll (zB bei überladenden Methoden). Im reinen
> C-Code würde man dies wohl eher versuchen auszuschließen.

Nein, würde man nicht.
Auch eine Bibliothek die in C geschrieben ist, wird ihre Argument auf 
Sinnhaftigkeit testen. Was der erste Teil dieses Absatzes aussagen soll, 
ist mir nicht klar. Mir kommt aber vor, du verwechselst hier 
Compile-Time mit Run-Time. Die Auflösung welche Methode, abhängig von 
den tatsächlichen Argumenttypen aufgerufen wird, wird vollständig zur 
Compile-Time gemacht. Ob der Compiler da 1/100 länger oder kürzer 
braucht, ist mir völlig egal. Auf die Laufzeit hat das sowieso keine 
Auswirkungen.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass du hier Sprache und Bibliotheken nicht unterscheidest 
und dir auch nicht bewusst bist, dass C praktisch eine Untermenge von 
C++ ist?

> mit C++ ist es ja möglich durch wenige Funktionsaufrufe einen großen
> Teil an Rechenarbeit zu verrichten, wofür in C mehrere Funktionsaufrufe
> nötig wären.

Beispiel?

> Sicherlich werden in den C++Bibliotheken mehrere Abfragen ausgeführt,

Warum sollte da in C und C++ verschieden sein? Das ist in erster Linie 
eine Frage des Geschmacks des Entwicklers, nicht der Sprache.

> zu testen ob die übergebenen Argumente richtig sind, bzw. um zu testen
> was mit ihnen geschehen soll (zB bei überladenden Methoden).

Bei ueberladenen Methoden waehlt der Compiler zur Compilezeit aus, 
welche Methode aufgerufen wird. Das war's dann schon und es kostet 
keinen Takt mehr Zeit.

> Im reinen C-Code würde man dies wohl eher versuchen auszuschließen.

Auch "reinen C-Code" kann man defensiv schreiben und alle Parameter 
pruefen.

Vieleicht solltest du erst etwas Programmiererfahrung sammeln und dich 
dann an die philosophischen Fragen wagen...

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C++ Funktionsaufruffe? OOP?

Da C++ eine weiterentwicklung von C ist, kann man damit auch funktional 
Programmieren. Dadurch sollten sich auch keinerlei laufzeit unterschiede 
ergeben. Das mit den Bibliotheken. Du kannst die vom Kompiler verwenden, 
oder auch andere. Mann kann auch einen anderen Kompiler verwenden, der 
besser ist.

C++ ist eine OOP Sprache. sie beitet ganz andere bzw weit mehr 
Sprachmittel an um Probleme zu lösen als C. somit sind sie für mich 
nicht direckt vergleichbar.

Wenn du mit deiner Frage auf laufzeitunterschiede wegen der Virtulen 
Funktion Tabel anspielst. Versuche mal diese Funktionalität unter C zu 
erreichen. und dieses auch noch einigermassen wartbar zu halten.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Termite wrote:

> Wenn du mit deiner Frage auf laufzeitunterschiede wegen der Virtulen
> Funktion Tabel anspielst. Versuche mal diese Funktionalität unter C zu
> erreichen. und dieses auch noch einigermassen wartbar zu halten.

.... und dann auch noch schneller als ein indirekter function call über 
die V-Table. Das ist tatsächlich einer der Punkte, an der es praktisch 
unmöglich ist, mit C-Mitteln das zu schlagen, was ein C++ Compiler aus 
virtuellen Funktionen macht. Und wenn man tatsächlich auf etwas 
gleichwertiges kommt, baut man die vom Compiler benutzte V-Table nach 
:-)

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrung war beim MSP430 die, dass der IAR für C++-Code einen 
minimal höheren RAM und Codespeicher-Bedarf hatte als das C-Äquivalent. 
Der Grund dafür liegt vermutlich auch in der von Karl-Heinz erwähnten 
erhöhten Fehlersicherheit von C++.

Meiner Meinung nach überwiegen aber die Vorteile von C++ (z.B. 
Polymorphie), du mußt ja nicht gleich mit den übelsten OOP-Konstrukten 
um dich werfen und z.B. alles mit Templates aufblähen, sondern auch mit 
C++ nach dem Credo "Keep it smart and simple" arbeiten. Nur wenn du 
jedes Byte Programmcode rausquetschen willst und der µC schon aus dem 
letzten Loch pfeift, würde ich eine reine C-Lösung favorisieren.

Grüße,
Alexander

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex Wurst wrote:

> Der Grund dafür liegt vermutlich auch in der von Karl-Heinz erwähnten
> erhöhten Fehlersicherheit von C++.

Die wuerde ich schon gerne mal sehen.

> Meiner Meinung nach überwiegen aber die Vorteile von C++ (z.B.
> Polymorphie), du mußt ja nicht gleich mit den übelsten OOP-Konstrukten
> um dich werfen und z.B. alles mit Templates aufblähen, sondern auch mit
> C++ nach dem Credo "Keep it smart and simple" arbeiten.

Man kann mit Templates sogar Optimierungen bauen, die man in C nur 
erreichen kann, wenn man Makros einsetzt oder schlicht den Code kopiert. 
Dabei schneiden dann die Templates ausnahmsweise mal als leichter 
wartbar ab.

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl: Sorry, hätte ich dazu schreiben sollen: Meine Frage bezog sich 
ausschließlich auf die Schnelligkeit zur Laufzeit.

@Peter: Danke für deinen Tipp mit dem Erfahrungen sammeln, oder dass man 
Parameter sogar in C prüfen kann.

@all:
Vielleicht habe ich meine Frage einfach nicht gut genug gestellt. Ich 
meinte, dass ich im eigenen C-code genau weiß welche Parameter übergeben 
werden und somit bestimmte Abfragen eventuell ausschließen kann. Im 
C++Code kann ich diese Abfragen nicht gezielt ausschließen und somit 
wäre meine Frage vielleicht eher ob man trotzdem davon ausgehen kann, 
dass der Compiler diese Abfragen weg optimiert?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Wurst wrote:

> Im C++Code kann ich diese Abfragen nicht gezielt ausschließen

Warum nicht?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Alex Wurst wrote:
>
>> Der Grund dafür liegt vermutlich auch in der von Karl-Heinz erwähnten
>> erhöhten Fehlersicherheit von C++.
>
> Die wuerde ich schon gerne mal sehen.

Vergleich mal ein C++ Programm welches std::vector oder st::list 
verwendet, mit dem was ein durchschnittlicher C-Programmier zum Thema 
dynamisches Array oder Liste produziert. Stringverarbeitung stösst ins 
gleiche Horn. Die wenigsten C-Programme, die ich bisher gesehen habe, 
sind auf einem ähnlichen 'Sicherheitsniveau', die ein C++ Programm mit 
std::string aus dem Stand heraus erreicht.
Ein simples
   std::string input;

   std::cin >> input;

artet in C zu einer Nightmare aus, wenn es wirklich 100% funktional 
äquivalent sein soll.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Wurst wrote:

> @all:
> Vielleicht habe ich meine Frage einfach nicht gut genug gestellt. Ich
> meinte, dass ich im eigenen C-code genau weiß welche Parameter übergeben
> werden und somit bestimmte Abfragen eventuell ausschließen kann. Im
> C++Code kann ich diese Abfragen nicht gezielt ausschließen

Warum nicht?
Klar weißt du auch in C++ welche Parameter du übergeben kriegst.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Vergleich mal ein C++ Programm welches std::vector oder st::list
> verwendet, mit dem was ein durchschnittlicher C-Programmier zum Thema
> dynamisches Array oder Liste produziert.

Das ist genau das, was ich meinte: Nicht die Sprache und die 
Bibliotheken vermischen. Letztere sind zwar teilweise standardisiert, 
aber nicht Sprachbestandteil. Leider wird vor allem von neuerer 
Literatur das Gegenteil suggeriert - es bleibt aber falsch.

> artet in C zu einer Nightmare aus, wenn es wirklich 100% funktional
> äquivalent sein soll.

Wer Stringverarbeitung in C fuer einen Alptraum haelt, sollte es mit 
Java oder Python versuchen. Sicherlich ist std::string recht bequem, 
aber auch ohne ist das kein Hexenwerk.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Karl heinz Buchegger wrote:
>
>> Vergleich mal ein C++ Programm welches std::vector oder st::list
>> verwendet, mit dem was ein durchschnittlicher C-Programmier zum Thema
>> dynamisches Array oder Liste produziert.
>
> Das ist genau das, was ich meinte: Nicht die Sprache und die
> Bibliotheken vermischen. Letztere sind zwar teilweise standardisiert,
> aber nicht Sprachbestandteil. Leider wird vor allem von neuerer
> Literatur das Gegenteil suggeriert - es bleibt aber falsch.

Ähm. Nein.
die STL ist Bestandteil der Sprachdefinition C++, so wie sie im 
aktuellen ISO Dokument definiert ist.
std::list, std::vector, std::string mag anders implementiert sein als 
for, while, oder if. Logisch gesehen besteht aber kein Unterschied 
zwischen diesen Teilen. Sie alle sind im ISO-Dokument eindeutig 
beschrieben und ihre Eigenschaften wurden dort festgelegt. Wenn ein 
Compiler will, kann er std::string auch innerhalb des Compilers 
implementieren, so wie man das für for, while oder if macht. Der 
ISO-Standard hindert ihn nicht daran.

> aber auch ohne ist das kein Hexenwerk.

Hexenwerk nicht. Aber bis du in C die beiden oben geposteten Zeilen 
reproduziert hast, hast du schon 2 Bildschirmseiten C-Code produziert.
Genau das meine ich mit 'äquilvalenten Code zu vergleichen'
Ein
  char input[20];
  sscanf( "%s", input );
ist nun mal kein gleichwertiger Ersatz für den stream Input in einen 
std::string.

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein CodeBeispiel:
// C-Code:
free(pointer);     // wenn pointer == NULL ist, gibt es einen Fehler

// C++Code:
delete pointer;  // delete fragt zuvor (anscheinend) ab ob pointer == NULL ist
// Da ich bei der Anwendug eh schon wissen muss ob pointer Null ist, wäre ein weiteres Abfragen in meinem Fall vielleicht nicht nötig.

Wie gesagt, es war nur eine reine Verständnissfrage. Rein auf die 
Laufzeitgeschwindigkeit bezogen und unabhängig von Wartbarkeit des 
Codes.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ein CodeBeispiel:
> // C-Code:
> free(pointer);     // wenn pointer == NULL ist, gibt es einen Fehler

Siehst du, das meinen wir mit Erfahrung sammeln.
Wenn pointer gleich NULL ist, dann ist es völlig legal free() 
aufzurufen. In dem Fall passiert genau das gleiche, das auch bei einem
  delete pointer;
passieren würde. Nämlich: nichts.


> // Da ich bei der Anwendug eh schon wissen muss ob pointer Null ist,
> wäre ein weiteres Abfragen in meinem Fall vielleicht nicht nötig.

Es ist nie(!) nötig.
Ausser vielleicht in dem Fall, in dem ein NULL Pointer an dieser Stelle 
der Regelfall ist, dieses free() sehr, sehr oft gemacht wird und das 
auch nur dann, wenn man wirklich so in Zeitnot ist, dass die paar 
µSekunden multipliziert mit den vielen Millionen Aufrufen tatsächlich 
ins Gewicht fallen.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Ähm. Nein.
> die STL ist Bestandteil der Sprachdefinition C++, so wie sie im
> aktuellen ISO Dokument definiert ist.

Du hast mich ganz sicher richtig verstanden. Was du hier gerade 
produzierst, fuehrt den OP auf eine voellig falsche Faehrte.

>> aber auch ohne ist das kein Hexenwerk.
> Hexenwerk nicht. Aber bis du in C die beiden oben geposteten Zeilen
> reproduziert hast, hast du schon 2 Bildschirmseiten C-Code produziert.

Wenn dein Bildschirm nur 4 Zeilen hat vieleicht.

> Genau das meine ich mit 'äquilvalenten Code zu vergleichen'
> Ein
>   char input[20];
>   sscanf( "%s", input );
> ist nun mal kein gleichwertiger Ersatz für den stream Input in einen
> std::string.

sscanf zu benutzen ist auch voelliger Quatsch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Karl heinz Buchegger wrote:
>
>> Ähm. Nein.
>> die STL ist Bestandteil der Sprachdefinition C++, so wie sie im
>> aktuellen ISO Dokument definiert ist.
>
> Du hast mich ganz sicher richtig verstanden. Was du hier gerade
> produzierst, fuehrt den OP auf eine voellig falsche Faehrte.

Seh ich nicht so.
Gerade ein Anfänger sollte erst mal mit den std:: Klassen anfangen. 
Insbesonders std::string ist auf jedem Fall einer char[] Lösung 
vorzuziehen. Die Laufzeit ist nicht gravierend langsamer, die 
Möglichkeiten für Fehler sind jedoch bei char[] um einiges größer.

Und nein: Was ich verstanden habe ist, dass du die STL Klassen als nicht 
zu C++ gehörend betrachtest, deren Verwendung daher beim Vergleich der 
Möglichkeiten C vs. C++ als irrelevant einzustufen ist.

>>> aber auch ohne ist das kein Hexenwerk.
>> Hexenwerk nicht. Aber bis du in C die beiden oben geposteten Zeilen
>> reproduziert hast, hast du schon 2 Bildschirmseiten C-Code produziert.
>
> Wenn dein Bildschirm nur 4 Zeilen hat vieleicht.

Nicht wirklich.
Probiers aus. Schreib in reinem C die Funktionalität von getline nach. 
Und zwar mit allem drum und dran: Der String wird größer je mehr vom 
Input-Stream gelesen wird. Ist garnicht so trivial hinzukriegen, wenns 
dann auch noch performant sein soll.

(OK. 4 Seiten war übertrieben. Aber du weist schon worauf ich hinaus 
will)

> sscanf zu benutzen ist auch voelliger Quatsch.

OK. Dann ersetze sscanf mit fgets.
Selbes Problem.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Gerade ein Anfänger sollte erst mal mit den std:: Klassen anfangen.
> Insbesonders std::string ist auf jedem Fall einer char[] Lösung
> vorzuziehen. Die Laufzeit ist nicht gravierend langsamer, die
> Möglichkeiten für Fehler sind jedoch bei char[] um einiges größer.

Irgendwann muessen Anfaenger es lernen. Besser, sie lernen es wenn ihre 
Programme noch trivial sind. Es gibt schon zu viele Entwickler, die sich 
fuer erfahren halten und dann grausig versagen, wenn sie sich mal in 
einem "echten" Array bewegen muessen. Nicht umsonst stehen 
Buffer-Overflows immer noch an Platz 1 der haeufigsten Fehler - auch bei 
professionell erstellter Software.

Das gibt's auch in sonst keinem Handwerk, dass man die Grundlagen nach 
der Kuer lernt.

> Nicht wirklich.
> Probiers aus. Schreib in reinem C die Funktionalität von getline nach.
> Und zwar mit allem drum und dran: Der String wird größer je mehr vom
> Input-Stream gelesen wird. Ist garnicht so trivial hinzukriegen, wenns
> dann auch noch performant sein soll.

Ich habe das schon vor 15 Jahren getan, die Funktion funktioniert noch 
heute vorzueglich. Genau deswegen sollten Anfaenger nicht mit std 
anfangen, weil sie dann naemlich ewig glauben, ein bisschen 
Stringverarbeitung sei kompliziertes Voodoo. Die versagen dann in 
Umgebungen, wo sie nicht auf die dicken Bibliotheken zugreifen koennen, 
klaeglich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Karl heinz Buchegger wrote:
>
>> Gerade ein Anfänger sollte erst mal mit den std:: Klassen anfangen.
>> Insbesonders std::string ist auf jedem Fall einer char[] Lösung
>> vorzuziehen. Die Laufzeit ist nicht gravierend langsamer, die
>> Möglichkeiten für Fehler sind jedoch bei char[] um einiges größer.
>
> Irgendwann muessen Anfaenger es lernen.

Warum?
Ein C++ Programmierer braucht im Idealfall gar nicht wissen, welche 
Hacks und Klimmzüge und Fehlermöglichkeiten es mit der 
Stringverarbeitung in C 'füher' mal gab.

(Ich sag bewusst: Im Idealfall. Klar liegt dieser Idealfall nirgends 
wirklich vor. Aber wenn C#, VB oder Java Leute mit String Klassen wahre 
Erfolgsorgien feiern, gibt es keinen Grund warum C++ Leute das nicht 
auch tun könnten. Zumindest ist das Argument: Weil mir dann die Laufzeit 
in die Knie geht, meistens an den Haaren herbeigezogen und in der Praxis 
einfach nicht wahr)

> Besser, sie lernen es wenn ihre
> Programme noch trivial sind. Es gibt schon zu viele Entwickler, die sich
> fuer erfahren halten und dann grausig versagen, wenn sie sich mal in
> einem "echten" Array bewegen muessen. Nicht umsonst stehen
> Buffer-Overflows immer noch an Platz 1 der haeufigsten Fehler - auch bei
> professionell erstellter Software.

Du widersprichst dir hier selber.
Wenn ein C++ Programmierer konsequen std::string und Konsorten benutzt, 
dann gibt es keine Buffer Overflows mehr.
Die Buffer-Overflows, die du hier ansprichst, sind genau das Resultat 
dessen, wenn ein Programmiere meint er müsse aus 'Laufzeitgründen' auf 
die bereits vorhandenen Klassen verzichten und das Rad selber neu 
erfinden. (Oder wenn er aus Interface-technischen Gründen auf 
C-Libraries zugreifen muss und nicht weiß was er tut).

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Du widersprichst dir hier selber.
> Wenn ein C++ Programmierer konsequen std::string und Konsorten benutzt,
> dann gibt es keine Buffer Overflows mehr.

Es gibt noch andere Anwendungen fuer Arrays als Strings.

> Die Buffer-Overflows, die du hier ansprichst, sind genau das Resultat
> dessen, wenn ein Programmiere meint er müsse aus 'Laufzeitgründen' auf
> die bereits vorhandenen Klassen verzichten und das Rad selber neu
> erfinden. (Oder wenn er aus Interface-technischen Gründen auf
> C-Libraries zugreifen muss und nicht weiß was er tut).

Was in deiner Idealfall-Welt natuerlich nicht vorkommt. Und in die 
Verlegenheit auf einer Platform arbeiten zu muessen, wo ihm die stdlib 
nicht zur Verfuegung steht, kommt er da natuerlich auch nicht.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine sache gibt es in C++ uebrigens tatsaechlich, die einen ganz schnell 
zumindest Speicher kosten kann: RTTI. Das kann und sollte man bei 
avr-gcc mit -no-rtti abschalten.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Karl heinz Buchegger wrote:
>
>> Du widersprichst dir hier selber.
>> Wenn ein C++ Programmierer konsequen std::string und Konsorten benutzt,
>> dann gibt es keine Buffer Overflows mehr.
>
> Es gibt noch andere Anwendungen fuer Arrays als Strings.

Klar gibt es die.
Dann soll er std::vector benutzen und ist ebenfalls seinen Buffer 
Overflow zuverlässig los.

Du versuchst hier auf Biegen und Brechen die Verwendung von C-style 
Datenstrukturen in C++ zu verteidigen, mit nichts anderem in der Hand 
als: wir haben das schon immer so gemacht. Und weil das so ist, hat 
jeder die C-Methodik zu benutzen und das was ihm C++ dafür an die Hand 
gibt zu ignorieren.

Ausgangspunkt der ganzen Sache war ja: Ist es schneller selbst 
dynamische Strukturen zu verwalten (in C-Manier) als die entsprechenden 
C++ Mittel zu benutzen. Und die Antwort drauf kann nur sein: Wenn man 
Gleiches mit Gleichem vergleicht (also auch Fehlerfälle in Betracht 
zieht), dann ist es im Regelfall nicht schneller. Wohl aber ist die C++ 
Variante out of the box weniger fehleranfällig als wenn sich ein 
durchschnittlicher C-Programmierer an genau diesem Problem versucht.

> Was in deiner Idealfall-Welt natuerlich nicht vorkommt. Und in die
> Verlegenheit auf einer Platform arbeiten zu muessen, wo ihm die stdlib
> nicht zur Verfuegung steht, kommt er da natuerlich auch nicht.

Wenn dieser Thread in Mikrocontroller&Elektronik aufgetaucht wäre, wär 
ich darauf eingeganen. Wir sind hier aber in PC-Programmierung. Und ein 
C++ System auf einem PC hat eine ordentliche STL zu haben, ansonsten ist 
es kein C++ System.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:
> Peter Stegemann wrote:

>> Es gibt noch andere Anwendungen fuer Arrays als Strings.
> Klar gibt es die.
> Dann soll er std::vector benutzen und ist ebenfalls seinen Buffer
> Overflow zuverlässig los.

Ich traue durchaus einer Menge Leuten zu, einen Block Binaerdaten 
erstmal in einen Vector zu schieben, um ihn zu verarbeiten...

> Du versuchst hier auf Biegen und Brechen die Verwendung von C-style
> Datenstrukturen in C++ zu verteidigen, mit nichts anderem in der Hand
> als: wir haben das schon immer so gemacht. Und weil das so ist, hat
> jeder die C-Methodik zu benutzen und das was ihm C++ dafür an die Hand
> gibt zu ignorieren.

Unsinn. Immerhin bin ich hier im Forum regelmaessig der, der den Leuten 
immer wieder erklaert, dass man problemlos C++ auf dem Mikrokontroller 
verwenden kann. Das das nicht ginge ist genauso dogmatisch und falsch 
wie der Glaube, C++ ohne stdlib waere kein C++.

> Ausgangspunkt der ganzen Sache war ja: Ist es schneller selbst
> dynamische Strukturen zu verwalten (in C-Manier) als die entsprechenden
> C++ Mittel zu benutzen.

Was Ausgangspunkt war, kann eigentlich jeder ganz oben nachlesen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Unsinn. Immerhin bin ich hier im Forum regelmaessig der, der den Leuten
> immer wieder erklaert, dass man problemlos C++ auf dem Mikrokontroller
> verwenden kann. Das das nicht ginge ist genauso dogmatisch und falsch
> wie der Glaube, C++ ohne stdlib waere kein C++.
Ich hatte mal nen Lehrer, Zitat: Man kann sich auch ein Loch ins Knie 
bohren und Radieschen reinsäen schmunzel

Soll heißen: Gehen tut vieles, aber Nutzen und Aufwand (in jeder 
Hinsicht) muss man im Einzelfall abwägen.

Und inwieweit C++ schneller oder langsamer als C ist, wenn man sich die 
STL von Hand im Einzelfall nachbaut, ist eine Gradwanderung zwischen 
'universellem Code' (STL) und 'auf den Einzelfall optimiert' (manuell). 
Dadran wird sich auch nichts ändern -- die STL kann prinzipbedingt nicht 
jede erdenkliche Optimierung erriechen, auch wenn die für einen 
Programmierer ganz offensichtlich ist.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> die STL kann prinzipbedingt nicht jede erdenkliche Optimierung erriechen, auch 
wenn die für einen Programmierer ganz offensichtlich ist.

Andererseits ist es mit STL viel einfacher eine auch wirklich passende 
Datenstruktur+Algorithmus zu wählen.

In C++ ersetz ich einfach einen std::vector durch eine std::map, und der 
Großteil vom Code aussenrum bleibt gleich.
In C ein Array durch eine (noch handzuschreibende) Baum-Implementierung 
zu ersetzen, ist dagegen schon eine größere Fleissaufgabe, um die sich 
ein Programmierer gerne drückt.
Raus kommt dann eine version mit array und linearer Suche, die dann 
natürlich viel langsamer ist...

Ansonsten ist die Frage "ist C++ langsamer als C" ähnlich Sinnfrei wie 
"Ist ein Mountainbike schneller als ein Rennrad?" -- Hängt vom Gelände 
ab, und wie kräftig du in die Pedale trittst.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das klingt wie eine debatte unter jungprogrammierern. holt euch mal 
zuerst ein bischen mehr erfahrung (so um die 10, dann gilt man als 
"experte" oder "sachverständiger"), lest ein paar bücher über 
compilerbau (ui, da wird entzaubert) und schaut euch mal ein paar andere 
sprachen an, auch funktionale (C++ ist nicht funktional, auch wenn das 
da oben wer behauptet hat). und dann baut mal closures in c++ nach. von 
der geschwindigkeit mal ganz zu schweigen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ernst Bachmann wrote:
> Ansonsten ist die Frage "ist C++ langsamer als C" ähnlich Sinnfrei wie
> "Ist ein Mountainbike schneller als ein Rennrad?" -- Hängt vom Gelände
> ab, und wie kräftig du in die Pedale trittst.
Genau, was ich sagen wollte/will.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.