Warum programmiert ihr in C?

[volkard]

Cönner schrieb:

Jedes, in der Praxis geschriebene Programm in C++ ist etwas langsamer als ein C-Programm mit der gleichen Funktionalität

Tja, das ist jetzt vollig unbewiesener ein Glaubenssatz.

Cönner schrieb:

und das liegt an erster Linie an RAII (insbesondere wenn später erneut initialisiert wird), an falscher Nutzung von Sprachfeatures und an bestimmten Teilen der Standardbibliothek.

Inwiefern macht RAII langsamer? Welche technischen Aspekte bewirken das. Wo sind die Mehr-Anweisungen, die dadurch entstehen? Das kannst Du doch sicherlich herausarbeiten, es ist so wunderbar konkret. Uder die Aussage zurücknehmen.

Klar, falsche Nutzung von Sprachfeatures würde langsam machen. Aber dem halte ich entgegen, daß man zum Greifen nah lauter nette Sachen hat, allem Voran
- schnelle stings (kein strlen dauernd und strcat muß nicht das Ende suchen), CopyOnWrite-Optimierung bei mmachen Compilern sogar SmallString-Optimierung.
- std::map und dadurch oft plattenlastige Eingabe und prozessorlastige Sortierung verschränkt.
- std::queue und damit einen effizienten Universalzwischenspeicher für viele kleine Sachen.
Das müßte dafür sorgen, daß Leute, die die Tendenz haben, Sprachmittel falsch zu verwenden, daß diese Leute auf der C-Seite einfach gute Techniken nicht nutzen können, weil zu weit entfernt.

Bestimmte Teile der Standardbibliothek sind langsam. Aber keine dieser Teile benutzt man in grafischen Anwendungen oder in Spielen. Gell? Gib es zu.

Cönner schrieb:

volkard schrieb:

Genau das sage ich über cout und Konsorten.

Ausserdem ist jedes C++ Programm grösser als das in C.

OK. time-space-tradoff. Ich zahle ein wenig Speicherkosten, um ein wenig Geschwindigkeit zu gewinnen.

Cönner schrieb:

Aus reinem Interesse (ich programmiere manchmal auch in C++): Was verwendest du an der Stelle von den Standard-Streams (boost::iostreams kanns ja nicht sein)?

Eine experimentelle Eigenimplementierung. Die kann fast nichts; dafür zahle ich auch fast nichts.

[volkard]

mngbd schrieb:

volkard schrieb:

Damit ist gemeint, daß wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion vergleichen tun, um mal zu schauen, was das Inlinen hier bringen bewirken könnte. Das ist doch auch für C-Leute ein wichtiges Ergebnis.

Zumindest ich wüsste das gerne. Gibt es da verlässliche Vergleichsdaten?

Du könntest die Datenbasis um eine zweite Messung erweitern. Ich hoffe, daß auf moderneren als meinem Prozessor der Unterschied kleiner wird, weil der Prozessorbauer noch mehr Druck in die Performance des Funktionsaufrufs gelegt hat.

[cppschmecktnicht]

@volkard: Wenn etwas nach Scheiße schmeckt muss ich das nicht immer bis auf die Molekülebene beweisen. C++ hat sich ja nicht durchgesetzt weil es so eine tolle Sprache ist, sondern weil einige unfähige Leute in der Industrie den damaligen Versprechungen von C++ geglaubt haben. Das C++ letztendlich crap ist brauch wohl nicht mehr bewiesen zu werden und dass das hier in einem C++ auch niemand zugeben würde ist ja wohl auch klar. Eine Verbreitung einer Sache sagt noch lange nichts über dessen Qualität aus.

[volkard]

Cönner schrieb:

Dass sort in dieser Geschwindigkeit in C nicht möglich ist, stimmt nicht. Es ist ein bisschen schwieriger, da reicht die Standardbibliothek nicht aus, dafür gibt es unzählige alternative Bibliotheken.

Ja, kann sein. Ich kenne leider keine, weil ich so selten noch C betreibe. Natürlich geht das.

Der C++-Compiler kann mitunter ein identisches Programm etwas schneller machen als der C-Compiler, aber ein Asm/C/C++-Gemisch nenn ich dann nicht mehr C++.

Ich rede gar nicht von Asm drinne. Daß die STL voller Asm wäre, war eine Behauptung von einem C-Troll. Ich bezeichne Dich nicht als C-Troll. C-Trolle sind hier die paar, die völlig ohne Begründung uder zu 100% falsch begründet rumplärren, wie schlecht C++ sei, also Leute wie Didaktiker5. Als ich mit std::sort mal genau vor die Lupe nahm, war keine einzige Zeile Assembler drin.

Cönner schrieb:

Vielleicht geht es mit C++, durch die Exceptions auf einfache Weise das Programm so zu optimieren, wie es in C nur sehr umständlich hinzukriegen ist, aber vermutlich ist mit der Verwendung von Makros mit Assemblercode das gleiche in C mit sehr viel mehr Aufwand möglich.

Das glaube ich nicht. Mit Makros recht einfach kriegt ihr das Inlining im Sort hin. Aber zero cost exceptions, da sehe ich jetzt keinen Angriffspunkt.

Cönner schrieb:

Solche theoretischen Szenarien mit einem maximal ausgereizten C++-Compiler den C-Compiler auszustechen sind mit der Einbindung von Assemblercode wieder hinfällig, rein theoretisch kann man in C++ wie in C reinen Assembler schreiben, es gilt C=C++=Assembler.

Ja, das war bis vorhin auch so. Natürlich ist der Test irrelevant.
Aber dann kotzt Du so eine Scheiße, wie daß C++-Programme immer langsamer seien als C-Programme. Dann laß Dir auch sagen, daß C-Programme erst konkurrenzfähig sind, wenn der Programmierer gut Assembler kann, während die STL bereits bei Halbprofis für eine Geschwindigkeit im Datenmanagement sorgt, die in C kaum ein Vollprofi hinkriegt.
Laß es doch einfach dabei bewenden, daß Du C++ nicht magst. Aber Du mußt das nicht mit Behauptungen untermauern, C++ sei prinzipiell schlecht. Das ist nicht der Fall. Und da fange ich dann auch an, zu widersprechen. Geht ja zum Glück recht einfach, indem ich technische Fakten ausgrabe, statt sozioökonomischen Vermutungen.

Cönner schrieb:

Jedes, in der Praxis geschriebene Programm in C++ ist etwas langsamer als ein C-Programm mit der gleichen Funktionalität

Hier. Das ist einfach nicht der Fall.

[Zeus]

cppschmecktnicht schrieb:

@volkard: Wenn etwas nach Scheiße schmeckt muss ich das nicht immer bis auf die Molekülebene beweisen. C++ hat sich ja nicht durchgesetzt weil es so eine tolle Sprache ist, sondern weil einige unfähige Leute in der Industrie den damaligen Versprechungen von C++ geglaubt haben. Das C++ letztendlich crap ist brauch wohl nicht mehr bewiesen zu werden und dass das hier in einem C++ auch niemand zugeben würde ist ja wohl auch klar. Eine Verbreitung einer Sache sagt noch lange nichts über dessen Qualität aus.

Trotzdem steck der Troll in Scheiße!

[volkard]

cppschmecktnicht schrieb:

@volkard: Wenn etwas nach Scheiße schmeckt muss ich das nicht immer bis auf die Molekülebene beweisen.

Du mußt nicht beweisen, daß es *Dir* nicht schmeckt.

Aber wenn Du auftrittst und sagst, daß es allen Menschen nicht schmeckt oder gar schadet, mußt Du es beweisen oder zurücknehmen.

cppschmecktnicht schrieb:

Eine Verbreitung einer Sache sagt noch lange nichts über dessen Qualität aus.

Volkard mag Eigentore.

[menschaergeredichnichtmeh]

Ach Volkard mach doch nicht so einen Wind um C++. Wenn es hoch kommt macht C++ vielleicht 10% der gesamten Softwareentwicklung aus und das wird mit Sicherheit auch eher weniger als mehr werden. Spare dir doch deine Energie und schau dir an womit die restlichen 90% der Entwickler sich beschäftigen.

[Cönner]

volkard schrieb:

Inwiefern macht RAII langsamer? Welche technischen Aspekte bewirken das. Wo sind die Mehr-Anweisungen, die dadurch entstehen?

Es ist nicht immer per se langsam, aber es verunmöglicht, eine uninitialisierte Klasse zu bekommen.

Beispiel std::string:

std::string s; // alle Member werden auf 0 gesetzt
std::cin >> s; // erneute Initialisierung

[volkard]

Cönner schrieb:

volkard schrieb:

Inwiefern macht RAII langsamer? Welche technischen Aspekte bewirken das. Wo sind die Mehr-Anweisungen, die dadurch entstehen?

Es ist nicht immer per se langsam, aber es verunmöglicht, eine uninitialisierte Klasse zu bekommen.

Beispiel std::string:

std::string s; // alle Member werden auf 0 gesetzt
std::cin >> s; // erneute Initialisierung

Das ist nur ein Fehler in der Streamlib. Die ist (meine Meing dazu ist bekannt?) zum Abhaken.
Korrekt wäre natürlich

std::string(std::cin);

oder

std::string=std::cin.read_line();

oder

std::string=read_line(std::cin);

oder sowas.

[TheQ]

Warum hacken die meisten eigentlich auf der Geschwindigkeit rum? Selbst wenn ein C++ Kompilat teilweise!!! langsamere Ausführungsgeschwindigkeiten hat, so merkt man das heut in der Ausführung kaum. Manche sind hier echt sowas von c-onservative C-atholiken, die den Knall der Zeit nicht gehört haben.

OOP ist kein schlechtes Paradigma, weil es leichter zu erlernen ist, als strukturiert zu programmieren. Viele C-iddies sind doch nur neidisch, weil man mit C++ manches schneller hinbekommt, wofür man in C stundenlang knobeln musste.

Manche machen echt ne Weltanschauung draus.

[ProbeAbbo11]

Jeder der schon mal probiert hat ernsthaft C++ zu lernen wird verstehen warum ich lieber in C programmiere *hehe. Von 1000 Leuten die anfangen C++ zu lernen vermute ich mal bleibt einer dabei. Ich lese hier sehr oft im Forum und denke hier sind auch eine Menge Leute angemeldet aber ich schätze gerade mal 10-20 können wirklich C++. Ich glaube so etwas findet man bei keiner anderen Programmiersprache.

C++ ist sehr mächtig aber auch mächtig schwer zu beherrschen da kann man sich an jeder Stelle erneut ins Bein schießen, finde ich persönlich wesentlich schlimmer als in C und das ist schon mit viel Sorgfalt zu programmieren.

[TheQ]

ProbeAbbo11 schrieb:

C++ ist sehr mächtig aber auch mächtig schwer zu beherrschen da kann man sich an jeder Stelle erneut ins Bein schießen, finde ich persönlich wesentlich schlimmer als in C und das ist schon mit viel Sorgfalt zu programmieren.

Wer in C denkt, und C++ c-denkend programmiert, der wird sicher enttäuscht.
Man muss umdenken und eine neue Herangehensweise erlernen. Die syntaktischen Unterschiede zu C zu erlernen ist wahrlich nicht schwer. Schwer tut man sich, sein Denken und seine Herangehensweise zu ändern.

Es ist keine Frage von Systemressourcen, es ist viel mehr eine philosophische Frage. Und manch begrenzter Horizont bleibt auch lieber an der Grenze des Tellerrandes

[Tellerrandschauer]

Ich mag C, Java und Python aber C++ überhaupt nicht. Über welchen Tellerrand soll ich denn noch schauen damit C++ für mich interessant werden könnte?

[Michael E.]

TheQ schrieb:

OOP ist kein schlechtes Paradigma, weil es leichter zu erlernen ist, als strukturiert zu programmieren

Das denke ich nicht. OOP ist schwer zu lernen. Meiner Meinung nach ist ein Hauptgrund dafür, dass ein gutes objektorientiertes Design nicht dem intuitiven Verständnis von Objekten entspricht, das man jenseits der Programmierung hat. Die Vorteile von OOP zeigen sich erst dann, wenn man es einigermaßen verstanden (Literator, Praxis) hat.

[nachtfeuer]

ich finds ehrlich gesagt ein wenig offtopic, wenn einer fragt, warum sich das Programmieren in C für einen selbst empfiehlt, dann Antworten lesen muss, warum sich C++ nicht empfiehlt oder C nicht.
Ich findes es zwar nicht so schlimm, wenn z.B. so ein C++ Jünger diesen oder jenen Thread zur Kalibrierung seines Weltbildes benutzt, und unter Trollerei verstehe ich was ganz anderes, aber in diesem Zusammenhang hier erscheint es mir wirklich offtopic und höchstens als ein Hinweis darauf, dass das gewählte Weltbild auf wackeligen Beinen steht.

[zumLachenhier]

Was erwartest du in einem C++ Forum? Sachliche Argumente für C? Bis auf ein zwei halbwegs vernünftige Antworten war der Rest einfach nur billigstes C vs C++ getrolle. Da sind teilweise die Flamewars in den Webdesignforen lesenswerter.

Für ein Forum welches noch eine der beiden Sprachen favorisiert war es echt erbärmlich. Gibt es denn nicht eine einzige Person hier die wirklich Ahnung hat und neutral ist? Wie wir gesehen haben nicht.

Also macht den Thread zu und versucht es vielleicht in einem englischen Forum nochmal. Die Chance mal auf kompetente Leute zu treffen ist dort wesentlich höher.

[BasicMan01]

Die meisten kompetenten Leute verbringen ihre Zeit wohl eher mit programmieren als mit solchen Diskussionen. Bevor man das alles durchgelesen hat, hat man auch Java gelernt

[Didaktiker5]

volkard schrieb:

C-Trolle sind hier die paar, die völlig ohne Begründung uder zu 100% falsch begründet rumplärren, wie schlecht C++ sei, also Leute wie Didaktiker5. Als ich mit std::sort ...

Och nö, echte C++ - Trolle vergleichen die Laufzeit einer (dank Callback-Vergleicher) generische Sortierfunktion wie qsort() mit einer std::sort(), wo der Vergleicher bereits zur Compile-Time (nach Schablone) aufgelöst und folglich auch ge-inlined werden kann (d.h. der Funktionszeiger wird wegoptimiert).
std::sort() hat aber leider auch den Nachteil, dass dem verschwundenen Funktionszeiger dann zur Laufzeit keine alternative Vergleichsfunktion mehr zugewiesen werden kann.
Und wehe, dem Anwender fällt zur Laufzeit ein, dass er ein Feld statt nach Nachnamen beim zweiten Mal nach Wohnorten sortieren möchte, dann stösst man
mit der super-schnellen, aber leider ge-inlineten Vergleichsfunktion() von std::sort() auch sehr schnell an die Grenzen der Generizität.
Mit qsort() nimmt man einfach einen anderen Callback-Vergleicher (der natürlich zwangsläufig langsamer ist als eine inline-Vergleichsfunktion).
Du vergleichst also bei Deinen 'Laufzeit-Messungen' buchstäblich Äpfel mit Birnen, und scheinst es nicht mal zu bemerken.
qsort() ist selbst zur Laufzeit des Programms noch generisch.
std::sort() mit ge-inlineter (wegoptimierter call) Vergleichsfunktion natürlich nicht mehr -
Aber Hauptsache es hat sich ausnahmsweise mal ein C++ Konstrukt als 'schneller' 'erwiesen' ...
Hiermit gebe ich den Troll gerne zurück

MFG

@Cönner: Lass Dir nix vormachen, von den 'Experten' hier.

In C sieht man sich zuerst an, was auf einer Maschine überhaupt machbar ist,
was der Rechner gut und was er weniger gut kann usw.,
bevor man damit anfängt, große, abstrakte Pläne & Klassenhierarchien zu schmieden.
In C++ (und OOP allgemein) macht man's genau umgekehrt.

--> Welche Vorgangsweise führt wohl eher zu konkreten Ergebnissen?

MFG

[volkard]

Didaktiker5 schrieb:

In C sieht man sich zuerst an, was auf einer Maschine überhaupt machbar ist,
was der Rechner gut und was er weniger gut kann usw.,
bevor man damit anfängt, große, abstrakte Pläne & Klassenhierarchien zu schmieden.
In C++ (und OOP allgemein) macht man's genau umgekehrt.

Sagt wer? Ja, Shlaer und Mellor natürlich. Glaub denen nicht alles. Es gibt viel mehr Vorgehensweisen, die für bestimmte Projekttypen ihre Berechtigung haben.

[realistee]

Ich frag mich wie viele der Cler hier schon an richtig großer Software geschrieben haben mit GUI, Netzwerk, Datenbankanbindung etc. Wird bestimmt sehr übersichtlich der Code mit purem C.

Cler leben halt doch eher in ihrer kleinen Treiber/Hack-Welt, die eher dem Jahr 1980 als 2010 entspricht. In der realen Welt ist es den Kunden scheissegal ob die Anwendung 2% langsamer läuft. Der will einfach schnellstmöglich Ergebnisse, denn SW Entwicklung ist schweineteuer.

Aber ich erwarte nicht, dass das unsere unstudierten Cler verstehen.