C++ Tutorial - neuer Versuch
-
Ich hab mir mal deinen kleinen "Bericht" über CPP durchgelesen und ich denke du siehst ein paar Dinge vom falschen Standpunkt aus.
1. Man kann C/C++ schon zusammenfassen. Man kann mit einem C++ compiler auch Strukturierten Code a la C schreiben ohne Probleme. Es gibt klar ein paar Feinheiten (wenn man mal von OO absieht) in denen sich C und C++ unterscheiden. Aber ich persöhnlich kenne nichtmal alle und schreibe meine Programme oftmals aus einem Mix aus C und C++ und hatte bisher absolut keine Probleme. Abgesehen davon ist der Syntax von Schleifen, Anweisungen etc exakt gleich bei beiden, was ebenfalls dafür spricht es zusammen zu erwähnen.
2.C++ ist jawohl schwer. Für einen Anfänger. Man kann nicht immer davon ausgehen das jemand gleich oben einsteigen kann. Ich habe mit QuickBasic angefangen. Mich dann über VB, Delphi und Java zu C/C++ gehangelt und bin bei C++ geblieben. Ich würde nie behaupten das C++ einfach ist. Aber ich finde es vom Syntax und den Möglichkeiten her am besten.
3. Man kann Java, C++, PHP etc nicht so ohne weiteres miteinander vergleichen. Jede Sprache ist für ein spezielles Aufgabengebiet am geeignetsten. Mann kann dynamische Webseiten auch über CGI von einem C++ Programm generieren lassen. Aber da PHP die meisten Funktionen für Stringbearbeitungen und Datenbanken ohne großes Drumherum sehr einfach bereitstellt ist es meist dafür die erste Wahl (neben PERL vielleicht). Java ist einfacher Plattformunabhängig zu gestalten als C++. Die meisten Programme sind sehr eng an eine API eines bestimmten OS gebunden, weshalb das portieren doch einen Aufwand darstellt.
Java hat meiner Meinung aber ebenfalls einen nachteil. Man ist darauf angewiesen das es eine Virtuelle Machine für das betreffende OS gibt und ich persöhnlich finde Java sehr lahm und finde das aufgezwungene Konzept von OO sehr doof. Man kann dort ohne Klassen praktisch nicht arbeiten was die Sache meist etwas wirr erscheinen lässt. Über Schnickschnack wie Garbage-Collection lässt sich streiten.3. Schnellentwicklung ist bei C++ meist nur ohne viel Komfort möglich. Sprich ich habe dann nur sehr eingeschränkte Möglichkeiten. ABER: Wenn ich einfach nur schnell ein blödes Fenster haben will, dann nehme ich VB oder Delphi und fertig. (Somal es ja auch gute Bibliotheken a la MFC für C++ gibt, mit denen man auch recht komfortabel Fenster erstellen kann).
So das wärs auch soweit. Soll keine Beleidigung oder dergleichen sein, aber ich finde du hast manche Dinge einfach nicht objektiv genug gesehen.
Mal abgesehen davon ist es jedem sein eigenes Ding womit er programmiert.
FAZIT: Man kann sich nicht für alles auf eine Sprache festelegen, sondern sollte möglichst geschickt wählen um das beste Ergebnis zwischen Aufwand und Ergebnis zu erhalten.
-
Nochmal @Artchi
Man muss ja auch nicht zwingend Assembler lernen um gut Programmieren zu können. Es hilft einem aber doch ungemein wenn man versteht was mit dem Stack passiert und wieso lokale Variablen eben nur lokal sind usw.
Aber ein gutes Tutorial sollte sich nicht davor drücken über Bits und Bytes und den Aufbau der Datentypen (ok die FPU-Datentypen MÜSSEN nicht umbedingt dabei sein) zu reden. Das gehört einfach dazu, wenn man gescheite Programme schreiben möchte.
Es gibt ja auch zig Aspekte die man berücksichtigen kann. Will ich mein Programm speicherschonend schreiben, oder will ich viel Speed haben.
-
Artchi schrieb:
Selbst heute findet man in der Literatur immer noch keine Aussage, was da nun passiert. Es heißt immer lappidar: "Es wird ein neues Objekt erzeugt."
Weil das eben das schöne an Abstraktion ist. Du weisst es nicht. Jeder Compiler kann machen was er will Da sind unglaubliche Optimierungen drinnen.
Ich habe letztens meinem Cousin, der Delphie an der Techniker-Abendschule lernt, erklärt was eine Parameter-Übergabe by Refrence und by Value passiert. Was nun im Speicher und mit dem ProgrammCounter der CPU usw. passiert, hatte ihnen NIEMAND erklärt. Und ich muß sagen, mit ein paar Skizzen auf Papier hat er verstanden was da genau passiert, wenn er eine Funktion aufruft. Und warum es by Value und by Referece gibt.
Und warum ist das wichtig? Sicher, bei einfachen Sachen wie nem simplen Funktionsaufruf kann man es auch noch vernünftig erklären, aber wie sieht es mit komplexeren Sachen aus, wie zB Fenster, Threads, etc. Das artet dann einfach aus. Ab einem gewissen Zeitpunkt versteht man eh was da in etwa passiert - aber alles genau zu wissen ist übertrieben - wer hat schon die Zeit das alles genau zu lernen?
Deshalb programmiert man ja in High Level Sprachen und nicht in ASM
-
TeeJay schrieb:
Aber ein gutes Tutorial sollte sich nicht davor drücken über Bits und Bytes und den Aufbau der Datentypen (ok die FPU-Datentypen MÜSSEN nicht umbedingt dabei sein) zu reden. Das gehört einfach dazu, wenn man gescheite Programme schreiben möchte.
Blödsinn.
Was hat Programmieren mit der internen Darstellung von der Datentypen zu tun.
Ich habe zB absolut keine Ahnung was PHP mit einem
$i=5;
macht. Es interessiert mich auch nicht Und dennoch schreibe ich 'gescheite' Sachen in PHP.
-
Shade, ohne Kentnisse der Grundlagen von Bits und deren Operatoren passiert aber irgendwann sowas:
-
@Shade of Mine
Dein Beispiel $i=5 ist sehr dämlich gewählt.
PHP ist eine Scriptsprache die für blöde Entwickelt wurde.
Soll nicht heißen das jeder der in PHP codet blöd ist.
Aber bei PHP gibts eigentlich so gut wie nix auf das du aufpassen müsstest.
Du kannst die Datentypen hin und her konvertieren ohne das jemand meckert und es funzt prima. Für den Aufgabenzweck als Interpretersprache ist das eine super Lösung.Aber es lässt sich nicht mit C vergleichen.
-
Shade Of Mine schrieb:
Artchi schrieb:
Selbst heute findet man in der Literatur immer noch keine Aussage, was da nun passiert. Es heißt immer lappidar: "Es wird ein neues Objekt erzeugt."
Weil das eben das schöne an Abstraktion ist. Du weisst es nicht. Jeder Compiler kann machen was er will Da sind unglaubliche Optimierungen drinnen.
Und warum ist das wichtig? Sicher, bei einfachen Sachen wie nem simplen Funktionsaufruf kann man es auch noch vernünftig erklären, aber wie sieht es mit komplexeren Sachen aus, wie zB Fenster, Threads, etc. Das artet dann einfach aus. Ab einem gewissen Zeitpunkt versteht man eh was da in etwa passiert - aber alles genau zu wissen ist übertrieben - wer hat schon die Zeit das alles genau zu lernen?
Deshalb programmiert man ja in High Level Sprachen und nicht in ASM
Ich habe ihm ja keinen ASM Code aufs Blatt Papier geschrieben und erwarte das auch nicht in der Literatur. :p Es geht dabei um das Prinzip, was im Hintergrund passiert. Es geht auch nicht um Dinge die ein Compiler optimiert.
Aber, was passiert wenn ich folgendes mache:
{ int i = 0; i++; }
Man kann jemandem das so erklären, das auf einem Papierstapel ein neues Blatt gelegt wird, auf dem eine "0" drauf steht. Der Stapel wird durch die geschweifte Klammer eingeleutet. Bei i++ wird der Wert auf dem Papierblatt um eins erhöht (radier weg, schreib 1 rein). Bei der geschweiften Klammer wird das Blatt Papier wieder vom Papierstapel genommen und zerrissen.
So, wenn man dann noch erklärt, was es mit dem Papierstapel im Hauptspeicher des Computers zu tun hat, hat man schon seeeehr viel gewonnen und der angehende Coder kann sich alles viel besser vorstellen.
Ich hab das hier vor einiger Zeit versucht zu erklären:
http://www.kharchi.de/cppratgeber.htmMan kann mit einfachen Mitteln erklären was im Hintergrund passiert. Das wurde damals zu C64-Zeiten regelmäßig in dem 64er Magazin praktiziert in Verbindung mit Assembler.
-
Master_Max schrieb:
Zum #include und dem nicht folgenden sprichpunkt.
Ich wollte den Leser nicht im ersten Kapitel auch noch erzählen das include nicht kompiliert wird, sondern ein Präprozessor befehl ist und das auf Präprozessorbefehle kein Strichpunkt folgt.Das halte ich für fatal. Erst falsche Sachen erzählen und dann später korrigieren ist nur bei ganz kleinen Sachen zur Vereinfachung möglich. Wenn ich was lese und nach der Hälfte heißt es: Das vorher kannste vergessen, das war falsch, so isses richtig, dann frage ich mich doch, was da noch so alles falsch ist...
-
Das oben angesprochene Problem mit dem falschen Anfang an die Programmierung kenne ich,
sieht bei mir in der Klasse genau so aus und wenn mich dann manche Mitschüler mal
was fragen kann ich nur antworten: "Kann ich dir so jetzt nicht erklären", weil
einfach zu viel wissen fehltIch habe C++ auch gelernt und weiß was es im Hintergrund tut, aber ich muss es doch
nicht soo genau wissen, es reicht ja wenn man es weiß ohne es in ASM nachschreiben
zu können.
So kann man by reference und by value auch verstehen ohne zu wissen was genau geschieht,
so weiß ich, dass bei by reference nur ein Zeiger kopiert wird und bei by value
der Inhalt des gesamten Objektes, mehr muss ich doch gar nicht wissen um zu verstehen,
weshalb man große Objekte am besten by reference übergibt.
-
Marc++us schrieb:
Shade, ohne Kentnisse der Grundlagen von Bits und deren Operatoren passiert aber irgendwann sowas:
Ja, irgendwann.
Aber ich kenne genug Tutorials die gleich nachdem Datentypen erklaert wurden hardocre bitmanipulation machen. Natuerlich soll man bitmanipulation koennen - aber in vielen Tutorials hat es eine viel zu wichtige Stellung.
Meine ersten 2-3 Anwendungen kann ich getrost ohne bitmanipulation schreiben.
Lieber erstmal die wesentlichen Sachen kapieren.
-
Danke an alle, ich werde jetzt einmal schauen was sich noch daraus machen lässt,
dann melde ich mich wieder.MfG Max