Warum programmiert ihr in C?

Mein kleiner Bastelfreund, schon mal daran gedacht dass es in C einfach nicht so viele Probleme gibt die in einem eigenen Forum geklärt werden müssen???

K&R wird immer mal wieder neu gedruckt und geht auch gebraucht immer noch gut weg. Herr Wolf(Das neue soll mal gut sein ;-)) bringt auch seine neuen Bücher raus und Bücher wie "Moderne C-Programmierung" gibt es auch immer mal wieder. Die Aussage dass keine neuen Bücher zu C raus kommen ist schlicht weg falsch. Es sind viel weniger als in C++, aber in C gibt es auch nicht so viel zu lernen wie in C++. Bald wird ja an C++ wieder was reingefrickelt und dann gibt es wieder ganz tolle Bücher und jeder kann wieder neu kaufen.

Wie leicht ein Werkzeug zu handhaben und zu erlernen ist ist auch schon ein Kriterium für dessen Effektivität.

Die Sprache ist so schrecklich dass man echt den Hut vor den Leuten ziehen muss die sich sowas freiwillig antun.

Shade Of Mine

cppfrickelkram schrieb:

Mein kleiner Bastelfreund, schon mal daran gedacht dass es in C einfach nicht so viele Probleme gibt die in einem eigenen Forum geklärt werden müssen???

dh die Anfänger in C sind heute soviel besser als die Anfänger von vor 5 Jahren?
Nicht schlecht.

Da hast du was falsch verstanden, aber egal. Auf jedenfall reicht das Forum hier für die paar rein C-Spezifischen Problemchen, auch wenn es technisch eher auf 8. Klasse Hauptschulniveau ist, die Javaleute habe sich da schon weiter entwickelt. In C++ hat man ja zu den paar C-Stolpersteinchen noch etliche mehr, allein in OOP kann man so viel verkehrt machen da sind Zeiger ja Waisenknaben dagegen.

Lustig finde ich ja dass C++ler immer zum Teil C programmieren müssen, aber nicht umgekehrt *hehe

Da braucht ihr hier gar nicht so viel diskutieren schon allein das ich von vielen Sprachen aus auf C Binaries zugreifen kann ist das Killerargument für C. Es wird schon lange nicht mehr alles in nur einer Sprache geschrieben und für solche Hybridprodukte macht es keinen Sinn C++ zu nehmen, da es kaum zu anderen Hochsprachen kompatibel ist. Meine Meinung nach braucht C++ bald kein Mensch mehr. Ein C/Java C/Python Produkt wird immer viel effektiver sein als alles in dem schrecklichen C++ zu schreiben und ständig aufpassen zu müssen ob man sich nicht wieder mal ins Bein geschossen hat. Wenn du dir nicht die heftigsten Gedanken beim C++ Programmieren machst biste langsamer als Java und C# und das frustriert einfach und macht auch keinen Spaß.

An alle Anfänger Finger weg von C++, die Sprache ist nur was für Masochisten. In keiner anderen Sprache kann man soviel Bockmist produzieren. Die meisten C++ Bücher sind nicht umsonst Schrott, sondern weil selbst Experten mit der Sprache ihre Probleme haben.

SeppJ

cppforfreaks schrieb:

Da hast du was falsch verstanden, aber egal. Auf jedenfall reicht das Forum hier für die paar rein C-Spezifischen Problemchen, auch wenn es technisch eher auf 8. Klasse Hauptschulniveau ist, die Javaleute habe sich da schon weiter entwickelt. In C++ hat man ja zu den paar C-Stolpersteinchen noch etliche mehr, allein in OOP kann man so viel verkehrt machen da sind Zeiger ja Waisenknaben dagegen.

Lustig finde ich ja dass C++ler immer zum Teil C programmieren müssen, aber nicht umgekehrt *hehe

Ich glaube das alles liegt zu großen Teilen an einem Herrn Wolf.

Das mit den Büchern zu C war ja der größte Stuß hier. Allein für 2010 habe ich bei Amazon auf die schnelle drei neue C-Bücher gefunden.

volkard

nurnochkopfschüttel schrieb:

Das mit den Büchern zu C war ja der größte Stuß hier. Allein für 2010 habe ich bei Amazon auf die schnelle drei neue C-Bücher gefunden.

Stimmt, es gibt nicht keine neuen C-Bücher. Vielleicht wenige, aber nicht keine. War falsch von mir.

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.