Warum programmiert ihr in C?

Bei C-Codezeilen hat man eine genauere Vorstellung davon, welche Instruktionen
der Compiler daraus generieren wird.
Insbesondere sind mit sequentiellen C-Strukturen die meisten I/O Operationen prinzipiell erheblich besser optimierbar ('Marshalling') als mit
einer OO-Hochsprache. Ein 'Objekt' (= zusammengehörige Daten) gelangen mit
fread(), fwrite(), memmove(), memcpy() auch 'zusammengehörig' sowie mit erheblich weniger IN / OUT Instruktionen an ihren Zielorten an.
Die Elemente einer OO-Klassen-Instanz liegen demgegenüber selten (bis überhuapt
nie) 'hintereinander' im Speicher, sind oft stark fragmentiert (kreuz und quer
im Speicher verstreut), und können so nur mit sehr vielen INs oder OUTs (und
natürlich auch nur in sehr kleinen Portionen) ausgegeben oder eingelesen werden.
Mit C++ ohne C-Basis ist die Gefahr größer, suboptimale Klassen zu entwerfen,
bei denen in keinster Weise darauf Rücksicht genommen wird, wo die Daten
eigentlich im Speicher untergebracht sind. Und deren Instanzen dann nur noch mühsam in sehr vielen kleinen Teilschritten und deshalb zuhöchst langsam für I/O Operationen zu gebrauchen sind, weil eben eine Instanz einer solchen
Klasse nicht mehr 'in einem Stück' mit memmove(), fwrite() etc. verschoben werden kann. Und egal wie 'gratis' die OOP-Ausnahmenbehandlung oder sonst etwas
an C++ auch sein sollte: Letzten Endes werden sich I+O in ein C++ Programm stets
erheblich langsamer gestalten als in C, weil eben in C++ einfach keinerlei Rück-
sicht auf ein Instruktions-Freundliches Speicherabbild einer Klassen-Instanz
genommen wird.
Und genau aus diesem Grund läuft ein C-Programm auch idR bis zu 30 x schneller als ein (scheinbar/oberflächlich betrachtet) äquivalentes OOP - C++ - Programm:
Weil der C++ - Compiler nämlich auch 30 x mehr I/O - Instruktionen erzeugen muss, während ein C - Compiler (dank Rücksichtnahme des C-Programmierers auf
ein I/O - Freundliches Speicherabbild seiner Daten) nur eine benötigt.
So unglaublich das für den (maschinenfernen) C++ Programmierer auch klingen
mag, aber letzten Endes sind I/O - Instruktionen der ganz große 'Flaschenhals' in jedem Programm und erfordern die meiste Zeit. In einem C++ Programm müssen aber ganz besonders viele I/O - Instruktionen codiert werden, weil die Daten so verstreut im Speicher liegen (man pfeift ja als C++ - Skript Kiddie auf die Speicherverwaltung, gelle?). Und das ist der eigentliche Hauptgrund, warum C++
Programme erheblich langsamer sind als äquivalente C - Programme (und als C-Programmierer nimmt man auch mehr Rücksicht darauf, dass man seine Daten sequentiell im Speicher unterbringt, und nicht kreuz und quer verstreut, wie es bei den Elementen von <vector>, <list>, <map> usw. der Fall ist.
Weniger I/O - Instruktionen im Maschinencode
== 30 x schneller als C++ - Bloatware.

K.A. in wie weit meine Ausführungen jetzt für C++ - 'Experten' ohne Ahnung von der Arbeitsweise einer CPU obektiv oder überzeugend erscheinen mögen, aber
vielleicht gibt's ja doch noch ein paar C++ Leute die aus C oder Assembler kommen (und die es nicht erst nach C++ gelernt haben). Denn das wären hier die wirklichen 'Experten', und die lachen sich wohl bei jedem Satz über die angeblich gleichwertige Performance von OOP-<vector>-C++ -Code
und C - Code mit Ausnutzung sequentieller Daten speziell aus I/O Gründen ins Fäustchen. Auch für Leute, denen bisher noch nicht bewusst war, wo eigentlich die meiste Rechenzeit verloren geht
(die objektorientierte Datenmodellierung in einer Hochsprache == I/O-feindlich)
sollte jetzt klar sein, warum C-Programme um den Faktor 30 und noch höher schneller ausgeführt werden können als C++ - Bloatware:
Es liegt an der prinzipiell unterschiedlichen Art, Daten (== Objekte) zu modellieren.
(I) C == Sequentiell == I/O - freundlich.
(II) C++ == Fragmentiert == I/O - feindlich.
Deshalb liebt der C-Programmierer das Array, während es der C++ - Programmierer aus Prinzip hasst, wie der Teufel das Weihwasser scheut, können in einem C++ Programm die Speicherorte (auch zusammengehöriger Objekte) gar nicht zufällig genug im Speicher verstreut sein. Jeder neue C++ - Anfänger hier in den Foren, der es wagt, in seinem C++ - Quellcode ein Array zu verwenden, bekommt Vorwürfe als Antwort, warum er es nicht mit <vector> oder sonstwas versucht, und dass er Arrays in C++ tunlichst niemals verwenden darf.
Kann man fast täglich ein derartiges Thema im C++ - Forum hier finden.
Was das für I/O bedeutet -> siehe oben. Und genau deshalb wird ein C++
Programm auch niemals auch nur annähernd an die Ausführungs-Geschwindigkeiten eines funktional identen C-Programms herankommen. Weil die Daten in C++ (und OOP) prinzipiell falsch und modelliert werden. Und das nur deshalb, weil kein moderner C++ - Programmierer einen C - oder Assembler- Background hat.
Denn in letzterem Fall würde das nicht passieren. Dann nimmt man nämlich auch in C++ mal ein Array sowie viele andere C - Konstrukte (keine überlangen Schleifen, bei Funktionsaufrufen mit Far Calls sparsamer sein, wenn Near Calls möglich sind usw.).
Und weiß auch, warum man es tut. Die C++ - SkriptKiddies des neueren Schlags, die C++ (falscher Weise) vor C erlernen, werden deshalb stets mindestens 30x langsamere Programme schreiben, als professionelle C - Programmierer (und natürlich auch professionelle C++ - Programmierer, die mit C angefangen haben und die Grundlagen, warum und wie der Rechner ihr Programm überhaupt ausführt, nicht verlernt haben).

MFG

Du schreibst als unregistrierter Troll an einem Samstag Morgen so einen langen Bullshit Text. Du bist zu bedauern.

volkard

Experte666 schrieb:

K.A. in wie weit meine Ausführungen jetzt für C++ - 'Experten' ohne Ahnung von der Arbeitsweise einer CPU obektiv oder überzeugend erscheinen mögen,

Das weiß ich auch nicht.
Aber für C++-Experten mit Ahnung von der Arbeitsweise der CPU erscheinen Deine Ausführungen nicht begründet.

Zur Ansicht ein Monster-Objekt.

struct S1{
   int a;
   int b;
};
struct S2{
   int c;
   int d;
};
struct S3{
   int e;
   int f;
};
struct S4{
   int g;
   int h;
};
struct S12{
   S1 s1;
   S2 s2;
};
struct S34{
   S3 s3;
   S4 s4;
};
struct S1234{
   S12 s13;
   S34 s34;
};
S1234 s1234;

Glaubst Du wirklich, daß in s1234 die weit entfernten Elemente a-g völlig wild verteilt im Speicher liegen?

Falls nicht, baue mal ein praxisrelevantes Objekt, das grottenlangsam ist, und das in C viel schneller wäre. Das wird dann erstens in C viel unpraktischer sein, und zweitens kann ich Dir zeigen, wie man es in C++ mindestens genauso schnell bekommt.

Volkard hat es schön beschrieben. In C++ muss man meist rumtricksen um auf die Geschwindigkeit von C zu kommen.

Will man ohne C-Elemente wie Zeiger etc. mit C++ die Geschwindigkeit von C erreichen so ist dies fast nicht möglich. Ich kann es auch nicht oft genug betonen solange man kein C++ und OOP Experte ist wird das C++ Programm nie und nimmer an ein in C erstelltes Programm rankommen. Bei Anfängern ist mit Sicherheit auch mal ein Faktor 30 drinne in dem ein oder anderen Fall. Aber in der Regel biste du mit C++ nur halb so schnell unterwegs denn die wenigsten C++ Programmiere sind wirkliche Experten auf ihrem Gebiet. Es wird auch kaum noch neue Programmierer geben die C++ so gut lernen werden um damit an C ranzukommen.

In der Praxis sind so gut wie immer die C Programme schneller und natürlich auch schlanker, ob das nun theoretisch anders geht ist uninteressant. Ein JIT-Compiler könnte auch schneller sein als ein statisches Kompilat, ist es aber in der Praxis auch nicht.

Ich würde mal sagen 90% aller C++ler produzieren schöne Bloatware wo selbst die Javaraner sich das Lächeln nicht verkneifen können.

Schöne WE noch und viel beim Rumquälen mit C++ *kicher

volkard

F18oder17 schrieb:

Bei Anfängern ist mit Sicherheit auch mal ein Faktor 30 drinne in dem ein oder anderen Fall. Aber in der Regel biste du mit C++ nur halb so schnell unterwegs

Unfug. Zeig ein Beispiel.

volkard schrieb:

F18oder17 schrieb:

Bei Anfängern ist mit Sicherheit auch mal ein Faktor 30 drinne in dem ein oder anderen Fall. Aber in der Regel biste du mit C++ nur halb so schnell unterwegs

Unfug. Zeig ein Beispiel.

char c[2]={'a'};
  c[1] = 'b';

string c("a");
  c+="b";

um sowas zu produzieren muß man aber schon verdammt schlecht programmieren...

muß natürlich c[3] sein... sollte erstmal richtig wach werden...

Das C++-Äquivalent wäre eher

string s(2,'a');
s[1] = 'b';

Man bedenke aber, dass std::string das intern verwendete char-array dynamisch allokiert (ebenso wie vector, das Array liegt dann antürlich in C++ ebenso an einem Stück im Speicher!), um Vergrößerungen zuzulassen.
Wenn man einen string konstanter Länge mit den üblichen Vorteilen (boundcheck, etc) gegenüber "nackten" Arrays braucht, kann man auf (z.B.) std::tr1::array<char, size> zurückgreifen.

Schaffner schrieb:

Das C++-Äquivalent wäre eher
string s(2,'a');
s[1] = 'b';
Man bedenke aber, dass std::string das intern verwendete char-array dynamisch allokiert (ebenso wie vector, das Array liegt dann antürlich in C++ ebenso an einem Stück im Speicher!), um Vergrößerungen zuzulassen.
Wenn man einen string konstanter Länge mit den üblichen Vorteilen (boundcheck, etc) gegenüber "nackten" Arrays braucht, kann man auf (z.B.) std::tr1::array<char, size> zurückgreifen.

übder die performance speicher dynamisch zu allokieren haben wir uns hier schon oft unterhalten, das will ich nicht wieder aufwärmen. wie ich schrieb würde ein guter c++ entwickler vermutlich etwas anderes verwenden. aber so wie es c'ler gibt die

char *c = calloc(3,sizeof(char));
c[0] = 'a';
c[1] = 'b';

verwenden (hier im forum schon öfter aufgetaucht...) nehmen c++'ler sicher auch (ist sicher auch schon im forum schon aufgetaucht...)

string c("a");
c+="b";

schlechter code lässt sich in jeder sprache schreiben

volkard

__-- schrieb:

char c[2]={'a'};
  c[1] = 'b';

string c("a");
  c+="b";

Naja, falls es so einen schlechten C++-Anfänger gibt, dann müssen wir ihm auch einen schlechen C-Anfänger entgegenhalten, gell?

char c[2]="a";
  strcat(c,"b");

volkard

hehe schrieb:

muß natürlich c[3] sein... sollte erstmal richtig wach werden...

Manche (ich nicht) nehmen gerne C++, weil ihnen in C++ sowas nicht passiert.