Was bringt es mir C zu lernen?

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/329926

Mein 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.

Nathan

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.

volkard

dachschaden_off schrieb:

Mein Favorit:
https://www.c-plusplus.net/forum/329853

Die Frage nach einem beliebigdimensionalen Array wird in jeder Sprache zu einem Müllprogramm führen.
Klassischer Fall von GarbageIn=>GarbageOut.

Nathan

(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?

Nathan

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.

volkard

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?

volkard

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?

volkard

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: 3446438947

DAS 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: 3827313058

Der 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: 3868940057

Cojones pur. Sollte eigentlich bessere Bücher zum Metaprogrammieren geben, hab gerade keins auswendig auf der Pfanne.
Modernes C++ Design | ISBN: 3826613473

Sicherheit zum Schluss natürlich erst.
Exceptional C++ | ISBN: 3827317118

Ab dann eher freies Gefecht. Zum Beispiel
Programming Pearls | ISBN: 0201657880

Und 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.

Nathan

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.

Mechanics

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.

volkard

Unknown34b schrieb:

Was ich jetzt nicht verstehe ist dass hier jemand sich nach der Aufklärung…

Der wird sich auch noch einen Wolf https://www.c-plusplus.net/forum/272350-full kaufen. :p

Das ist ja ein vernichtender Thread, wie sieht es mit den anderen Bücher von Galileo aus, wie z.B. Schröndinger programmiert C++? Kann man wirklich generell von dem Verlag abraten?

Ich habe mir jetzt die Bücher "Einführung in die Programmierung mit C++ (Pearson Studium - IT)" von Herrn Stroustrup und das Buch "Effektiv C++ programmieren" von Scott Meyers bestellt.

volkard

Unknown34b schrieb:

Das ist ja ein vernichtender Thread, wie sieht es mit den anderen Bücher von Galileo aus, wie z.B. Schröndinger programmiert C++?

Scherzkeks, das ist eine Reihe.

Unknown34b schrieb:

Kann man wirklich generell von dem Verlag abraten?

Also es kann ja immer mal passieren, daß ein guter Verlag ein schlechtes Buch raushaut, bei Addison-Wesley wüßte ich gerade eins, das leicht vom sonstigen Verlagsruf abweicht. Bei Galileo weiß ich gerade keins.

Es liegt aber nicht am Verlag und auch nicht an den Autoren, sondern eigentlich wehrt sich der Verlag gegen die 5-Sterne-Bewertungen, obwohl sie den unbedarften Fachbuchkäufer so unglaublich gewinnbringend täuschen:
http://www.heise.de/tp/foren/S-Stellungnahme-von-Galileo-Press/forum-131043/msg-14326107/read/

SLx64

Unknown34b schrieb:

Kann man wirklich generell von dem Verlag abraten?

Nein das würde ich nicht sagen. Die Bücher von Jürgen Wolf sind da schon die schlechteren Beispiele aber das trifft nicht auf alle zu. Oft sind es leider die inhaltlichen Sachen die sehr fragwürdig sind, da viele Bücher zum einen gut geschrieben und von der Qualität recht gut sind. Also als Fazit - man sollte immer mal einen Profi durchblättern lassen und wenn der Inhalt passt, hat man schöne Einsteigerbücher.

SeppJ

SLx64 schrieb:

Also als Fazit - man sollte immer mal einen Profi durchblättern lassen und wenn der Inhalt passt, hat man schöne Einsteigerbücher.

Beim Galileoverlag erfolgt aber anscheinend keine solche Qualitätsprüfung, daher kann man schon sagen, dass man allem was aus dem Verlag kommt, skeptisch^* gegenüber stehen sollte.

^*: Skeptischer, als man es sonst wäre. Man sollte natürlich niemals ganz unskeptisch sein.