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?
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.
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...
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.
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 :-)
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
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.
@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?
Hans Wurst wrote:
> Im C++Code kann ich diese Abfragen nicht gezielt ausschließen
Warum nicht?
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
1 | std::string input; |
2 | |
3 | std::cin >> input; |
artet in C zu einer Nightmare aus, wenn es wirklich 100% funktional äquivalent sein soll.
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.
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.
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.
ein CodeBeispiel:
1 | // C-Code:
|
2 | free(pointer); // wenn pointer == NULL ist, gibt es einen Fehler |
1 | // C++Code:
|
2 | delete pointer; // delete fragt zuvor (anscheinend) ab ob pointer == NULL ist |
3 | // 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.
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.