Warum programmiert ihr in C?
-
C Fan schrieb:
Vielleicht solltet ihr das also mal auf einer Plattform messen, bei der die STL nicht zu 90 % aus Assemblercode besteht.
Zu offensichtlich solltest du nicht trollen :p
-
Realistisch schrieb:
Da C und C++ hier fast das gleiche machen wundert es nicht dass das Ergebnis ähnlich ist. Hier hat mal jemand was über Raytracer geschrieben, welcher jedes Semester neu an einer Uni implementiert wird und hier zeugt sich das wenig überraschende Bild das C am schnellsten ist gefolgt von C++ und etwas die 4fache Zeit benötigt Java.
Schneller wie in C geht es nur mit Assembler alles andere ist großer Humbug.
Die Uni sollte mal D probieren.
-
Wie man hier im Thread sieht wissen selbst viele STL-Fanboys teilweise nicht, was sich hinter der STL verbirgt. Getreu dem Motto: "da haben sich mal welche bestimmt Gedanken gemacht" ...
Also mir is das zu wenig...
C-Code ist C-Code ist C-Code
( und wenn man es ordentlich macht, kommt sogar ganz passabler Assembler-Code raus )
-
Also ich würde niemanden hier (fast niemand) ein STL Fan-boy bezeichnen. Die Herren wissen schon von was sie sprechen. Von Volkard weis ich dies zumindest.
Ich schreibe fast ohne STL und habe sie auch nicht bis ins letzte Detail studiert, darum kann ich nix dazu sagen, da ich eben hauptsächlich C schreibe mit Assembler.Aber ich würde behaupten dass doch sicher die eine oder ander Sache in ASM
programmiert ist.Ich hab es einfach gern, wenn ich sehe was da passiert. Das ist einfach bei STL nur mit reversing machbar. Na gut lass das mal. Ist ja auch kein Problem. Für alles hat man einfach keine Zeit. Doch werde sicher mal zeit finden mal die STL voneinander zu nehmen. Bin gespannt...
Und wer sagt C sei hässlicher Code.... Ich finde C ist wenn man einen guten Style hat eine der schönsten Sprachen die es gibt.
-
It0101 schrieb:
Wie man hier im Thread sieht wissen selbst viele STL-Fanboys teilweise nicht, was sich hinter der STL verbirgt. Getreu dem Motto: "da haben sich mal welche bestimmt Gedanken gemacht" ...
Also mir is das zu wenig...
Es ist klar, dass du einen Tick schneller bist, wenn du die StdLib-Implementierung nimmst und den Overhead (und Stringlängenberechnung, du Schelm 
) auslagerst. Ich habe auch nie behauptet, dass man mit einer speziellen Implementierung nicht schneller sein kann als die STL. Wir sind aber noch Meilen entfernt von einem Faktor 10 oder gar 30, der hier so gerne genannt wird.Ich finde die Philosophie übrigens befremdlich, dass man alles selbstbauen muss, um nach ner Woche was Fehleranfälligeres, aber vielleicht um 20% Schnelleres gebaut zu haben. Dabei merkt man den Performanceunterschied in den allermeisten Fällen gar nicht.
-
So ziemlich jeder C Fanboy hat sich in diesem Thread jetzt blamiert. Koennen wir eigentlich mal langsam schliessen, oder?
-
C Fan schrieb:
knivil schrieb:
STL bedeutet Standard Template Library.
Und bei mir:
C -> 674 ms
C++ -> 396 msAufruf: g++ main.cpp -O3
Tja, da siehst man mal wieder.
Würdet du mal bitte gcc anstatt g++ zum compilieren nehmen?
gcc ist der C Compiler, nicht g++!
Welche grosartige Veraenderung erwartest du? gcc uebersetzt in einen "intermediate code", der wohl bei dem Programm mit FindC fuer C++ als auch fuer C sehr aehnlich ist. Dann wird auf die Zielplattform abgebildet. Um deinem Wunsch zu entsprechen, C mit gcc -O3 main.c (und entfernen aller C++-Elemente) lieferte 668ms.
Schneller wie in C geht es nur mit Assembler alles andere ist großer Humbug.
Ich kenne Spielzeugbeispiel, da ist Haskell sogar schneller (entsprechender Compiler vorausgesetzt, nicht ghc).
-
cppungleichstl
Das ist glaube ich jedem klar !
-
@ Autor "malneugierig"
Na, Frage beantwortet?
-
Es waren vielleicht zwei Postings bei die mir als Antwort gereicht hätten. Der Rest war halt Kindergarten aber habe auch nicht viel geistreiches in einem Programmierforum hier erwartet. Ich denke der Thread kann geschlossen werden und ich werde mir Fragen bezüglich Programmiersprachen verkneifen. Leider haben Anfänger immer zu erst die Frage welche Sprache die beste ist und welches Buch man sich kaufen soll etc. Also werde ich hier bestimmt noch viel Crap lesen müssen, was aber bestimmt normal menschlich ist. Es ist halt billigstes Verhalten ähnlich ist es mit Job, Autos, Kleidung, Technik usw jeder will immer für sich die beste Wahl getroffen haben und vergisst dabei aber das diese Wahl nicht automatisch auch für einen anderen gut sein muss.
Wenn 99 Leuten blaues Licht beruhigt und einer nicht, dann heisst das nicht das blaues Licht beruhigend wirkt sondern dass es dies meistens tut. Vielleicht blödes Beispiel aber ich denke es ist klar was ich damit sagen will.
-
Einen hab ich noch: Linux ist besser als Windows.
-
Erkenner des Besseren schrieb:
Einen hab ich noch: Linux ist besser als Windows.
Und deshalb lassen sich WINAPI Programme/Module aus den frühen 90ern selbst nach 20 Jahren noch problemlos kompilieren und ausführen (und gewiss auch 2020 noch - eine API für die Ewigkeit.)
Eine in Punkto Umfang (&Robustheit) her vergleichbare LINAPI, die auf jedem Linux-System verfügbar oder gar halbwegs abwärts- sowie aufwärtskompatibel konzipiert wäre, gab und gibt es nicht. Bei der Nutzung von OS-Schnittstellen muss man das Rad für Ubuntu, RedHat, Suse und Debian jeweils auf's Neue erfinden und kann große Teile des Quelltexts in spätestens 3 Jahren verschrotten.
Wir lernen: Wirklich portable (sowohl alte als auch neue Windows-Rechner), wiederverwendbare und beständige (einem etablierten Standard - der sich nicht alle 3 Jahre ändert - folgende) Quelltexte wird man wohl noch ziemlich lange nur für Windows schreiben können.
-
StandardFan schrieb:
Eine in Punkto Umfang (&Robustheit) her vergleichbare LINAPI, die auf jedem Linux-System verfügbar oder gar halbwegs abwärts- sowie aufwärtskompatibel konzipiert wäre, gab und gibt es nicht.
Das kann es auch nicht geben, da die Unix Philosophie schon immer lautete:
* Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen.
* Schreibe Programme so, dass sie zusammenarbeiten.
* Schreibe Programme so, dass sie Textströme verarbeiten, denn dies ist eine universelle Schnittstelle.Und daran hielt sich viele Jahre lang auch Linux und das ist gut so.
Die Winapi ist dagegen Bloatware und heutzutage im Vergleich zu den Alternativen wie gtk+ & co nicht mehr zeitgemäß und eine Zumutung.Die Unix Pipes sind aber selbst heute noch ne super Sache.
Unix Pipes und die dafür entwickelte Tools wie grep, bc, ls usw. funktionieren schon seit Jahren und sind abwärts und aufwärtskompatibel.
http://de.wikipedia.org/wiki/Unix-Philosophie
Unix und damit auch Linux verfolgt das KISS Prinzip und C tut genau da gleiche.
Die WinAPI fällt also aus der Reihe.
-
Na ja, die WINAPI hat mal als "Graphischer DOS-Aufsatz" angefangen, nicht als
eigenständiges und unabhängiges Teil wie bei Unix/Linux. Diese saubere Trennung
existiert halt nicht, also wird auch seit Urzeiten aller Müll mitgeschleppt.Versuche mal, das einem "Entscheider" zu erklären ...
-
Und jedes mal wieder die alten Geschichten.
C ist besser als C++. Nein C++ ist besser als C ...Und jeder der Code mischt ist noch schlimmer als die jeweilige Gegenseite...
*gähn* langsam geht mir eure sturheit auf den Sack
Öffnet euch doch mal für Neues. Die Cpp-ler lernen endlich mal memset, memcpy und Pointerarithmetik zu benutzen und die C-ler lernen mal ordentliche Kapselung und Objektorientierung
-
Michael E. schrieb:
Wir sind aber noch Meilen entfernt von einem Faktor 10 oder gar 30, der hier so gerne genannt wird.
Vielleicht kommen wir auf den Faktor, wenn bei C++ im Millisekunden-Takt Exceptions fliegen und abgefangen werden
Das dürfte ganz schön Performance kosten Bei C# jedenfalls ist das der Performance-Tod
-
It0101 schrieb:
Vielleicht kommen wir auf den Faktor, wenn bei C++ im Millisekunden-Takt Exceptions fliegen und abgefangen werden
Das dürfte ganz schön Performance kosten Wills Du wirklich auf der Performance des Exception-Handlings und der Fehlerbehandlung in C herumreiten?
-
@Volkard: ich weiß, dass dir die Fehlerbehandlung in C nicht behagt
-
Und man muss auch brachten dass Exception-Handling anderens implementieren kann und dementsprechend auch andere Kosten hat: Dwarf, SJLJ, SEH,...
-
It0101 schrieb:
Michael E. schrieb:
Wir sind aber noch Meilen entfernt von einem Faktor 10 oder gar 30, der hier so gerne genannt wird.
Vielleicht kommen wir auf den Faktor, wenn bei C++ im Millisekunden-Takt Exceptions fliegen und abgefangen werden
Das dürfte ganz schön Performance kosten Bei C# jedenfalls ist das der Performance-Tod
Nicht wirklich, aber na ja... Wenn du im ms-Takt Exceptions bekommst, hast du ganz andere Sorgen als Performance. Unabhängig davon heißen die nicht umsonst Exceptions und stellen Ausnahmen dar, die nicht zur Steuerung des Programmflusses benutzt werden (sollen).
