Was bringt es mir C zu lernen?
-
Haha sehr witzig. Nein mal bitte im ernst. Ich habe gelesen dass man in C viel mit Zeigern und Arrays zu tun hat und viele Ärgen sich über void* was auch immer es da für ein Problem mit gibt. Ich kann ein bisschen Java und würde aber gerne mal eine Sprache ausprobieren die nicht in einer VM läuft. Ist C++ eigentlich genauso schnell wie C? C++ bietet ja auch Klassen wie Java, ist das schwieriger zu lernen. Ich bin mir eben unschlüssig was es Vorteile gäbe, wenn ich C lernen oder ob ich es mal mit C++ als erstes probieren sollte.
Vielleicht könnt ihr mir helfen? Ich möchte so Bildbearbeitung machen, vielleicht auch einen kleinen Raytacer.
-
Unknown34b schrieb:
Ich habe gelesen dass man in C viel mit Zeigern und Arrays zu tun hat
Kommt darauf an, was du wie machst.
Unknown34b schrieb:
und viele Ärgen sich über void* was auch immer es da für ein Problem mit gibt.
void*
sind generische Zeiger, die auf alles mögliche Zeigen können. Dereferenzieren kannst du ohne Cast nicht, aber dafür Objekte beliebigen Typs darin speichern. Natürlich musst du dir irgendwo merken, was für ein Typ das jetzt noch mal war. Das fordert ein bisschen Programmieraufwand - ist aber immer noch besser als die Schmerzen, die die C++-Leute auf sich nehmen müssen (nein, SeppJ, ich will damit NICHT C++ bashen, wie es die letzten Tage der Fall war).Unknown34b schrieb:
Ich kann ein bisschen Java und würde aber gerne mal eine Sprache ausprobieren die nicht in einer VM läuft.
Warum?
Unknown34b schrieb:
Ist C++ eigentlich genauso schnell wie C?
Kommt darauf an, wie du es anwendest. Wenn du in C++ den gleichen Kram wie in C machst, wird es genauso schnell sein (vielleicht ist es ein ganz ganz ganz kleines bisschen mehr Aufwand, weil i.d.R. andere Symbole generiert werden), aber das ist wirklich marginal.
Wenn du allerdings die Vorteile von C++ nutzen willst - und die behandeln nun mal, dass du NICHT alles selbst machen musst - dann kann es schnell langsamer werden. Weil du in C++ nicht mehr die Speicherallokationen siehst. Du hantierst halt mit deinen Daten rum, aber du kümmerst dich nicht mehr so stark darum, wie die jetzt genau im Speicher liegen. Und anstatt dann Abkürzungen (keine Hacks) zu nehmen, weil du z.B. Speicher wiederverwerten kannst, lässt du dir dann krude Hacks einfallen, damit ein paar tausend Objekte den Speicher von ein paar anderen tausend Objekten erhalten können.
Unknown34b schrieb:
Vielleicht könnt ihr mir helfen? Ich möchte so Bildbearbeitung machen, vielleicht auch einen kleinen Raytacer.
Bin jetzt nicht in der Grafikprogrammierung drin, aber so was lässt man doch eher die Hardware (sprich GPU) machen, oder? Und dann ist es eher egal, welche Programmiersprache du verwendest, solange es für solche Funktionen in deiner Programmiersprache ein API gibt.
-
dachschaden_off schrieb:
Unknown34b schrieb:
und viele Ärgen sich über void* was auch immer es da für ein Problem mit gibt.
void*
sind generische Zeiger, die auf alles mögliche Zeigen können. Dereferenzieren kannst du ohne Cast nicht, aber dafür Objekte beliebigen Typs darin speichern. Natürlich musst du dir irgendwo merken, was für ein Typ das jetzt noch mal war. Das fordert ein bisschen Programmieraufwand - ist aber immer noch besser als die Schmerzen, die die C++-Leute auf sich nehmen müssenWas für Schmerzen? Wenn man das C++ Typsystem ausnutzt, können so Fehler gar nicht mehr auftreten. Wenn man in beiden Sprachen vernünftig programmiert, hat man keine Probleme.
Unknown34b schrieb:
Ist C++ eigentlich genauso schnell wie C?
Wenn du allerdings die Vorteile von C++ nutzen willst - und die behandeln nun mal, dass du NICHT alles selbst machen musst - dann kann es schnell langsamer werden.
Das ist absoluter Schwachsinn. Nur weil man die Vorteile von C++ verwendet, wird es nicht langsamer. Es wird langsamer, weil man mehr Sicherheit hat.
Weil du in C++ nicht mehr die Speicherallokationen siehst. Du hantierst halt mit deinen Daten rum, aber du kümmerst dich nicht mehr so stark darum, wie die jetzt genau im Speicher liegen. Und anstatt dann Abkürzungen (keine Hacks) zu nehmen, weil du z.B. Speicher wiederverwerten kannst, lässt du dir dann krude Hacks einfallen, damit ein paar tausend Objekte den Speicher von ein paar anderen tausend Objekten erhalten können.
Das ist der Sinn von Abstraktion. Und die "Hacks" nennen sich Allocatoren.
-
dachschaden_off schrieb:
void*
sind generische Zeiger, die auf alles mögliche Zeigen können. Dereferenzieren kannst du ohne Cast nicht, aber dafür Objekte beliebigen Typs darin speichern. Natürlich musst du dir irgendwo merken, was für ein Typ das jetzt noch mal war. Das fordert ein bisschen Programmieraufwand - ist aber immer noch besser als die Schmerzen, die die C++-Leute auf sich nehmen müssen (nein, SeppJ, ich will damit NICHT C++ bashen, wie es die letzten Tage der Fall war).Wovon redest du? Als der Threadersteller nach void*, Geschwindigkeit und C vs. C++ gefragt hat ist mir zuallererst in den Sinn gekommen, wie toll es doch ist, in C++ Templates zu haben, die das, was man in C mit großen Schmerzen über void* macht, kinderleicht, idiotensicher und zudem noch performanter umsetzen.
Unknown34b schrieb:
Ist C++ eigentlich genauso schnell wie C?
Kommt darauf an, wie du es anwendest. Wenn du in C++ den gleichen Kram wie in C machst, wird es genauso schnell sein (vielleicht ist es ein ganz ganz ganz kleines bisschen mehr Aufwand, weil i.d.R. andere Symbole generiert werden), aber das ist wirklich marginal.
Wenn du allerdings die Vorteile von C++ nutzen willst - und die behandeln nun mal, dass du NICHT alles selbst machen musst - dann kann es schnell langsamer werden. Weil du in C++ nicht mehr die Speicherallokationen siehst. Du hantierst halt mit deinen Daten rum, aber du kümmerst dich nicht mehr so stark darum, wie die jetzt genau im Speicher liegen. Und anstatt dann Abkürzungen (keine Hacks) zu nehmen, weil du z.B. Speicher wiederverwerten kannst, lässt du dir dann krude Hacks einfallen, damit ein paar tausend Objekte den Speicher von ein paar anderen tausend Objekten erhalten können.
Wieder Quatsch. Wie kann das C++-Programm denn langsamer sein? Wenn dein vergleichbares C-Programm schneller ist, dann macht es offensichtlich was anderes. In der Regel heißt das, es macht die Sache weniger gut. Denn wenn es das gleiche machen würde, dann könnte man es ja identisch in C++ machen. Letztlich ist doch fast alles, was C++ mehr kann gegenüber C, doch bloße Abstraktion. Man könnte für die meisten C++-Features einen Compiler schreiben, der aus dem C++-Code einen C-Code erzeugt. die ersten C++-Compiler haben genau das getan. Ausnahmen sind Features für die spezielle Hardwareoptimierungen existieren, die kann man so nicht direkt in C umsetzen und sind daher in C++ echt schneller (Exceptions beispielsweise). Aha! Also kann umgekehrt auch ein C-Programm nicht schneller sein als ein C++-Programm? Richtig. Und wenn man mal so typische Vergleichsprogramme ansieht, dann sind die beiden Sprachen fast immer ziemlich genau gleich schnell.
Die Frage ist, wie viel Aufwand man jeweils betreiben muss. Bei C wird's ja leider schon ziemlich flott ziemlich schwierig, komplexe Programme zu schreiben und ich würde auch nicht unbedingt sagen, dass es für weniger komplexe Programm in C überhaupt einfacher wird. Alleine schon einen Nutzer nach seinem Namen zu fragen und dann "Hallo <Nutzername>" auszugeben hat in C so seine Tücken. Ich vermute mal, dass du hier deine oben erwähnten Geschwindigkeitsvorteile siehst, weil man in C++ hier einen dynamischen String nehmen würde, in C aber ein statisches Array. Worauf ich eben die obige Erwiderung geben würde, dass das C++-Programm in dem Falle rundum glücklich macht, da es ohne jeden Zusatzaufwand mit jeder Art von Eingabe zurecht kommt, wohingegen das C-Programm dazu eben nicht fähig wäre und zudem der Programmierer sogar noch aufpassen muss, dass er nicht versehentlich eine Lücke einbaut, über die der Nutzer den Computer übernehmen kann. Und wenn der C++-Programmierer wollte, könnte er mit nicht sehr großem Aufwand ein ebenso beschränktes (und potentiell unsicheres) Programm schreiben, bloß ist die "bessere" Version in C++ eben die einfachere.
Oder das andere Extrembeispiel, was immer heran gezogen wird sind eben die void* von oben. In C++ bekommt man generische Programmierung geschenkt und als extra sogar noch Compilezeitoptimierung oben drauf, während man in C die Krücke über void* wählt, weil man sich nicht tot programmieren möchte. Das C-Programm könnte hier genau so schnell sein, wie das C++-Programm, aber man müsste eben jede Spezialisierung einzeln ausprogrammieren oder sich mit Makros rumärgern, was in C++ eben automatisch der Compiler für einen übernimmt.Und das sind nur die beiden Sprachfeatures, die du erwähnt hast, es gibt ja noch viel mehr.
Ich würde daher zusammenfassend sagen, dass C++ schon die weit überlegene Sprache ist und wenn man C++ kann, hat man keinen Grund, jemals was in C zu machen. Wenn man es denn kann. Denn dies ist meiner Meinung nach der große Nachteil: In C geht's von der Lernkurve her am Anfang (im Vergleich zu anderen Sprachen) erst einmal ziemlich steil hoch. Aber man ist schon bald am Gipfel. In C++ geht's kaum weniger steil los*, aber es hört und hört nicht auf und die Steigung nimmt auch nicht merklich ab. Nach 300-500 Seiten C-Lehrbuch kann man sagen, dass man in C mehr als nur fortgeschritten ist, dass man so ziemlich alles beherrscht und alle wichtigen Techniken kennt. In C++ reicht das nicht einmal für ein komplettes Grundlagenbuch, die alleine schon oft als 1000-Seiten-Wälzer kommen. Und nach deren Lektüre ist man gerade mal so weit, die einfacheren Werke für Fortgeschrittene zu verstehen
. Und beide Sprachen machen erst so richtig Spaß, wenn man sie gut beherrscht.
*: An einigen Stellen vielleicht sogar steiler. Beispielsweise wird beim obigen Beispielprogramm mit der Zeichenkette in C oft die "Krücke" über das statische Array akzeptiert, sogar als richtig angesehen. Auch wenn das entsprechende C++-Programm auf den ersten Blick aus einfacheren und besseren Code besteht, so ist da jedoch jede Menge hinter den Kulissen versteckt. Um das wirklich komplett zu verstehen und nicht bloß die magischen Worte nach zu plappern, muss man wesentlich mehr lernen als für das Verständnis von statischen Arrays und C-Strings.
-
Ok, also fasse ich mal zusammen:
C:
- ist ein wenig schneller als C++, wenn man dort nicht C Elemente einsetzt.
- wenn man vernünftig programmiert genauso einfach wie C++ zu handhaben.C++:
- Sicherer, daher ein klein wenig langsamer.
- höhere Abstraktion, das heißt es passiert viel hinter der Bühne.
- eventuell schwieriger zu lernen?Hmm, schwere Entscheidung. Was ist denn schwieriger zu handhaben, diese generische mit void*, oder das eher abstrakte, dafür komplexere?
Gibt es eigentlich in C mehr Sicherheitslücken als in C++ Programmen?
-
Getroffene Hunde bellen, würde ich sagen ...
Nathan schrieb:
Was für Schmerzen? Wenn man das C++ Typsystem ausnutzt, können so Fehler gar nicht mehr auftreten. Wenn man in beiden Sprachen vernünftig programmiert, hat man keine Probleme.
Schau dir doch mal die Fragen in der C++-Sektion an (erste Seite hat grad kaum leckere Beispiele, sage ich direkt). Ich schreib da zwar kaum rein, aber dennoch:
https://www.c-plusplus.net/forum/330038
https://www.c-plusplus.net/forum/329916
https://www.c-plusplus.net/forum/329926Mein Favorit:
https://www.c-plusplus.net/forum/329853
Nathan schrieb:
Das ist absoluter Schwachsinn. Nur weil man die Vorteile von C++ verwendet, wird es nicht langsamer. Es wird langsamer, weil man mehr Sicherheit hat.
Und was denkst du, was für Vorteile ich im Kopf hatte, als ich den Satz geschrieben habe?
iostream
? Containerklassen?Die Sicherheit habe ich übrigens gar nicht angesprochen. Aber es stimmt: C++-Anwendungen können sicherer programmiert werden. Aber diese Vorteile nehmen halt auch Freiheit beim Programmieren. Und in C kann man auch sicher programmiern. Kann, sage ich. Nicht so gute Programmiere bedenken natürlich etliche Sachen nicht (dass man auch mal über reservierten Speicher lesen kann). Aber die Leute, die sowas bedenken - ja, davon gibt es auch noch ein paar - die werden von den Vorteilen von C++ eher behindert.
Ich habe dazu auch mal was längeres geschrieben, abder der Text ist der Säuberungsaktion von SeppJ zum Opfer gefallen. Da habe ich jetzt nicht wirklich die Lust, das nochmal zu schreiben.
Nathan schrieb:
Das ist der Sinn von Abstraktion. Und die "Hacks" nennen sich Allocatoren.
Weil ich kaum noch C++ mache, würde ich dich dann gerne einmal fragen, wie du sicherstellst, dass der Speicher, denn du gerade als Buffer für das ent-gzippen einer Nachricht verwendet hast, im nächsten Call als Buffer für das gzippen verwenden kannst?
Die Musterlösung wäre wahrscheinlich, dass man dafür eine Bibliothek verwendet, die sich um die De- und Enkodierung kümmert, und die würde in einem Member dann auch den Buffer halten.
Aber wie kann ich diesen Buffer jetzt einem Dumper zuweisen, der mir im Programm Sachen wie in einem Hexeditor ausgeben soll? Wie kann ich den gleichen Buffer für das Einladen einer Datei verwenden? Wenn ich den Buffer später verwenden will, um Substringinformationen zwischenzuspeichern?Das, was ich gerade enumeriert habe, sind typische Anwendungsfälle von meiner Seite. Ich habe mir eine kleine Bibliothek in C aufgebaut, die all das kann. In C kann ich den Buffer einfach weiterreichen. Und selbst, wenn ich den Buffer einer Funktion geben will, die nicht zu meiner Lib gehört, kann ich den Buffer weiterreichen, indem ich direkt auf den Pointer zugreife.
In C++ verhindert das Typsystem normalerweise solche Späße. In C++ will man sowas vermutlich gar nicht haben, wegen der Sicherheit. Ist ja in Ordnung für die Leute, die das wollen. Ich will das nicht. Ich wüsste den Code brechen, um das gleiche in C++ machen zu wollen. Oder direkt wie in C programmieren. Aber C in C++ will ich nicht programmieren, da kann ich dann direkt bei C bleiben.
Soll ich eine Klasse schreiben, die mir all diese Funktionen für meinen Buffer bereitstellt? Klar, kann ich machen, aber den Code später zu warten stelle ich mir lustig vor.
Diese Fragen meine ich übrigens nicht sarkastisch. Vielleicht bin ich auch einfach naiv, was C++ angeht. Oder ich habe es damals falsch gelernt.
-
dachschaden_off schrieb:
Getroffene Hunde bellen, würde ich sagen ...
Aber Hunde, die bellen, beißen nicht. Oder so.
Nathan schrieb:
Was für Schmerzen? Wenn man das C++ Typsystem ausnutzt, können so Fehler gar nicht mehr auftreten. Wenn man in beiden Sprachen vernünftig programmiert, hat man keine Probleme.
Schau dir doch mal die Fragen in der C++-Sektion an (erste Seite hat grad kaum leckere Beispiele, sage ich direkt). Ich schreib da zwar kaum rein, aber dennoch:
[...]Ja, C++ hat z.T. recht komplexe Regeln. Das ist scheiße, aber dummerweise notwendig, wenn man bei so einer mächtigen Sprache ist.
Das, was ich gerade enumeriert habe, sind typische Anwendungsfälle von meiner Seite.
Das, was du gerade, beschrieben hast, ist ein Beispiel für Abstraktion. Und die ist Sprachen unabhängig. Ich kann auch in C++ das Abstraktionslevel niedrig setzen und es in C hoch machen. Das hat nichts mit der Sprache zu tun, sondern mit dem Design der Library.
Ich habe mir eine kleine Bibliothek in C aufgebaut, die all das kann. In C kann ich den Buffer einfach weiterreichen. Und selbst, wenn ich den Buffer einer Funktion geben will, die nicht zu meiner Lib gehört, kann ich den Buffer weiterreichen, indem ich direkt auf den Pointer zugreife.
Geht in C++ auch. Du forderst einmal via ::operator new Speicher an, der groß genug ist, und reichst dann den Pointer darauf herum.
C++ ist so designed worden, dass es keinen Grund gibt C zu verwenden, weil es alles ersetzen kann.In C++ verhindert das Typsystem normalerweise solche Späße.
C++ bietet einem immer noch Mitel und Wege das Typsystem zu umgehen, wenn man es denn braucht.
Soll ich eine Klasse schreiben, die mir all diese Funktionen für meinen Buffer bereitstellt? Klar, kann ich machen, aber den Code später zu warten stelle ich mir lustig vor.
Ich verstehe nicht ganz, was deine Bufferfunktionen sein sollen. Kannste vielleicht mal Code zeigen?
-
Unknown34b schrieb:
Gibt es eigentlich in C mehr Sicherheitslücken als in C++ Programmen?
Die Sicherheitslücken machen nicht die Sprache sondern die Programmierer.
In C ist es sehr leicht Sicherheitslücken zu bauen.
Die Sprache und die Standard-C-Library sind nicht besonders umfangreich. Man kann also schnell die Sprache lernen und ihre Eigenheiten kennenlernen.
-
dachschaden_off schrieb:
Mein Favorit:
https://www.c-plusplus.net/forum/329853Die Frage nach einem beliebigdimensionalen Array wird in jeder Sprache zu einem Müllprogramm führen.
Klassischer Fall von GarbageIn=>GarbageOut.
-
(extra ontopic Post, falls SeppJ wieder löschen möchte)
Unknown34b schrieb:
Hmm, schwere Entscheidung. Was ist denn schwieriger zu handhaben, diese generische mit void*, oder das eher abstrakte, dafür komplexere?
C++ hat recht komplexe Regeln. Man muss sie allerdings nicht alle können, um C++ Programme zu schreiben. Die Sprache ist extrem mächtig, aber viele dieser mächtigen Sachen braucht man nur wenn man extrem vielseitige Bibliotheken schreiben will.
C ist auf der anderen Seite wesentlich einfacher. Die Sprache ist um Längen kleiner und simpler. Dafür bietet sie auch nicht so viele Möglichkeiten.
Der C++ Compiler und die Standardbibliothek nehmen einen viel ab. In C ist es bspw. sehr aufwändig so etwas triviales wie eine beliebig lange Zeichenkette einzulesen. In C++ ist das dank der Standardbibliothek und den Sprachfeatures zwei Zeilen. Wenn man C++ richtig anwendet, ist es einfacher.
Meine Empfehlung ist es C++ zu probieren. Die Sprache ist wesentlich komfortabler für so einfache Sachen. Wichtig ist aber, dass du direkt modernes C++ lernst, ansonsten hast du nur Probleme, weil du quasi C programmierst, aber mit den ganzen Nachteilen, die C like Programme in C++ haben. Und dadurch lernst du auch das C Subset automatisch.Gibt es eigentlich in C mehr Sicherheitslücken als in C++ Programmen?
Wenn man C++ richtig anwendet, gibt es weniger Sicherheitslücken. Dasselbe gilt aber auch für C. Allerdings ist es in C++ wesentlich schwieriger, sich selber in den Fuß zu schießen. Schafft man es jedoch, ist gleich das Bein weg. (Bjarne Stroustrup, Erfinder von C++)
-
Ok, da spricht doch eigentlich alles für C++ und wenn etwas die Sprache nicht kann, dann kann man doch diesen kleinen Teil in C umsetzen, da dies ja auch in C++ enthalten ist, oder?
-
Unkown34b schrieb:
Ok, da spricht doch eigentlich alles für C++ und wenn etwas die Sprache nicht kann, dann kann man doch diesen kleinen Teil in C umsetzen, da dies ja auch in C++ enthalten ist, oder?
C++ unterstützt alles, was C auch kann, ja. Wenn man low level programmieren will, kann man das.
-
Unknown34b schrieb:
Ok, also fasse ich mal zusammen:
C:
- ist ein wenig schneller als C++, wenn man dort nicht C Elemente einsetzt.Unfug. C++ kann lahmer werden, wenn man damit Müll schreibt. C kann auch lahmer werden, wenn man damit Müll schreibt. Will nicht davon ausgehen, Müllprogramme zu bewerten. Müllcoder schreiben übrigens in Assembler noch viel langsamere Progs als in C oder C++.
C++ hat die Tendenz, wenn einfach hingekotzt, in Ein-Ausgabe lahm zu sein, aber im Rechnen schnell. Passt ja, wenn cin lahm ist wobei der Rechner pro Tastendruck eh 100Mio Takte sich langweilt.
Unknown34b schrieb:
- wenn man vernünftig programmiert genauso einfach wie C++ zu handhaben.
Unfug. Ruck zuck ist man in C an den Grenzen dessen, was in einen Kopf noch reinpasst. Lies Code von Knuth oder DJBernstein und weine, obwohl es der beste C-Code überhaupt ist. Klassischen Carmarck vor dem Frühstück und der Tag ist gelaufen.
Unknown34b schrieb:
C++:
- Sicherer, daher ein klein wenig langsamer.Ja, das ist üblich. Also um genau zu sein, ist es üblich in C gewisse Sicherheitprobleme schlicht zu ignorieren. Nicht aus Performancegründen, sondern weils in C so umständlich ist. Weil man im Lehrbuch nicht jedes Programm um 50% vergrößern will, während es gerade um ganz andere Sachen geht. Es sind wenige Handgriffe, aber langweilige. Tut man die, ist das Resuktat dann gleich.
Naja, fast gleich. Exceptions, sinnvoll und sparsam eingesetzt, machen C++ dann doch schneller als es ein C-Compiler überhaupt kann. Natürlich ist Dir die übliche Lösung in C schon klar, gell? Da ignoriert man das, was Exceptions brächten: Bei kritischen Fehlern graceful zu terminieren. Schlichtes exit bei offener Datenbankverbindung und hoffen, daß der Peer irgendwann die Netzwerksitzungen kickt. Komisch, daß jeder IRC-Server einen Admin namens Peer hat, der die Leute vom Netz trennt, wenn sie ein Weilchen offline sind.
Unknown34b schrieb:
- höhere Abstraktion, das heißt es passiert viel hinter der Bühne.
Nö. Außer <iostream> ist alles total geradlinig. Der übliche Baum in set/map wäre schwer nachzuprogrammieren und malloc/delete auch ein wenig. Alles andere ist so schlicht, daß es fast egal ist, ob die Standardlib mitgeliefert ist oder man es selber schreibt.
Unknown34b schrieb:
- eventuell schwieriger zu lernen?
Noch kritischer, was die Buchwahl angeht. Anfangs schwerer, später leichter. Bagger ist schwerer zu lernen als Schaufel. Anfangs. Aber Grabengraben ist dann mit dem Bagger leichter.
Unknown34b schrieb:
Gibt es eigentlich in C mehr Sicherheitslücken als in C++ Programmen?
Ja, circa eine Milliarde mal mehr. Das hat aber nix mit den Sprachen selber zu tun, sondern mit der Historie und dem Stil. Du wirst quasi keine Sicherheitslücken proggern, weder mit C noch mit C++, und wirst albern kichern, wenn Du bei anderen Sicherheitslücken siehst.
-
Ok, wie fange ich mit C++ an und wie viel Zeit muss ich für das Lernen einplanen?
-
Unknown34b schrieb:
Ok, wie fange ich mit C++ an und wie viel Zeit muss ich für das Lernen einplanen?
Breymann, Meyers, Struppi, Alexandrescu, Sutter, Meyers, GOF.
Für die Grundlagen sagen wir mal 15 Jahre. Aber bist viel früher professionell einsetzbar. Mit den richtigen Büchern und diesem Forum biste in einem Jahr in Sachen Technik/Stil/Sicherheit weit über dem, was in Unternehmen üblich ist. Erfahrung fehlt dann halt noch, aber das weiß der Arbeitgeber ja.
-
15 Jahre?!? In der Zeit habe ich ja drei Doktortitel erarbeitet
Ein Jahr geht ja noch. Könntest du mit noch die Buchtitel von den Autoren nennen, die du eben beschrieben hattest?
-
Bester Einstieg, wenn Abiturniveau vorhanden, finde ich. Alternativen wären der C++ Primer oder Thinking in C++. Vielleicht sogar der neue Struppi, wobei ich Struppi gerne nach Meyers hätte.
Der C++-Programmierer | ISBN: 3446438947DAS C++-Buch. Neue Auflage mit C++2014 finden! Wichtigsten Buch von allen. Sauschwer am Anfang. Deshalb nimmt man C++. Flüchtigkeitsfehler zu Compilerfehlern machen und Code schreiben, den man in 20 Jahren noch lesen kann. alternativlos.
Effektiv C++ programmieren | ISBN: 3827313058Der Meister selber spricht. Wichtig. Alle anderen bringen den Geist von C++ nicht so fein rüber. Unbedingt erst nach dem Meyers lesen, damit man die ganzen Hintergedanken kapiert. Da steht Zeug drin, was ein höflicher Autor auf 5000 Seiten verteilt hätte.
Die C++-Programmiersprache | ISBN: 3827330467
Evtl stattdessen den neuen Struppi nehmen, obwohls ein Einsteigerbuch ist. Wiederholen aus anderer Perspektive is ja keine Sünde.
Einführung in die Programmierung mit C++ | ISBN: 3868940057Cojones pur. Sollte eigentlich bessere Bücher zum Metaprogrammieren geben, hab gerade keins auswendig auf der Pfanne.
Modernes C++ Design | ISBN: 3826613473Sicherheit zum Schluss natürlich erst.
Exceptional C++ | ISBN: 3827317118Ab dann eher freies Gefecht. Zum Beispiel
Programming Pearls | ISBN: 0201657880Und nebenher Lisp lernen und was kleines damit schreiben. Und ja nicht auf den Algorithmen in C | ISBN: 3827371821 verzichten. Keine Bücher vom Galileo-Verlag. Keine Bücher über Gamecoding. Möglichst lange bei Konsoleanwendungen verbleiben und Techniken üben, denn GUI-Code ist Pfui-Code.
-
Was ich übrigens interessant finde:
Der Anfänger, der vor kurzem im C++ Forum gefragt hat, ob er C oder C++ lernen soll, hat sich für C entschieden.
Der Anfänger, der vor kurzem im C Forum gefragt hat, ober C oder C++ lernen soll, hat sich für C++ entschieden.
Lustiger Zufall.
-
Danke Volkard für die ausführliche Auflistung der Bücher, da habe ich erst mal was zu tun
Was ich jetzt nicht verstehe ist dass hier jemand sich nach der Aufklärung von C und C++ dann doch für C entschieden hat. C scheint doch nur Nachteile zu haben, so wie ich das jetzt mitbekommen haben. Und wenn man, wie gesagt, was spezielles von C mal braucht, dann hat man es ja eh bei C++ schon mit dabei. Man hat also in C++ wirklich ALLES, von rohen Zeigern und printf, bis zu Templates und STL. Wie kann man sich da freiwillig nur auf C konzentrieren? Man kann in C++ zu viel kompliziertes Zeugs nutzen wie man möchte, es ist aber nie ein MUSS.
-
Wenn es um den Thread geht, an den ich denke, wollte sich derjenige auf MC Programmierung konzentrieren, evtl. auch auf ganz kleine MC, wo nur C geht bzw. erste Wahl ist.
Es gibt tatsächlich Leute, die C bevorzugen. Ich denke, das kommt fast immer davon, dass man C++ nicht gut genug kann. Aber es kommt auch drauf an, was man machen will. Um auf das Beispiel von volkard zurückzukommen, vielleicht willst du nur einmal pro Jahr ein Beet umgraben und brauchst dafür keinen Bagger.