C++ Tutorial - neuer Versuch

Ihr habt ja recht und ich habe im ersten Abschnitt zuviel gemacht.
Ich wollte mal eine andere Art versuchen, gleich viel erklären und möglichst lustig. Den Leuten Fakten hinstellen mag ich nicht, aber wenn es im nächsten Kapitel erklärt wird und dann im vorherigen gesagt: Im nächsten wird´s erklärt, macht es einfach so. Dann ist´s auch Ok.

Wie gesagt, ich wollte etwas neues Probieren, ich wollte ganz kleine Happen machen damit jeder Leser, egal welche Zielgruppe es versteht und erfolgserlebnisse am Fließband bekommt. Ausserdem wollte ich es unterhaltsam schreiben.

Ich habe mir wohl zu viel vorgenommen und werde mal mein Konzept überdenken bevor ich weitermache, vielen dank an alle.

Artchi schrieb:

Aha? Und professionelle Programmierung wird nur in der Betriebssystem-Entwicklung betrieben???
.

Ok, ich werde es in:

Die in der Proffesionellen Software-Entwicklung wohl am meist verwendete Sprache.

ändern.

Shade Of Mine schrieb:

Master_Max schrieb:

Heute ist mir halt nichts inhaltlich neues eingefallen und ich wollte den Leser im ersten Kapitel vorallem vor falschen mains abschrecken.

Warum?
Sieh dir mal volkards Tutorial an - void main() ist zwar falsch, aber dennoch nicht so tragisch. Man kann auch mit void main() gute Programme schreiben

IMHO solltest du mehr erklären und mehr auf die Technik eingehen

Nach #include kommt kein Strichpunkt - ist zwar richtig, aber ich weiss jetzt nicht wieso - und werde es mir vermutlich nicht merken.

Sieh dir mal meinen Ansatz an: ich habe #includes und Co am Anfang nicht erklärt: ich habe gesagt: das ist so, und basta -> es reicht ja auch für den Anfang. Langsam entdeckt der Leser dann den Sinn - bis ich ihm das Konzept der Übersetzungseinheiten präsentiere.

Du musst es natürlich nicht genauso machen - aber vielleicht kannst du dir ein paar Ideen holen Bei mir hat es auch etliche Tutorials, Texte und Antworten und Erklärungen im Forum und Chats bedarft, bis ich einiger maßen vernünftige Texte schreiben konnte.

Wie gesagt, ich habe im ersten Tutorial sehr viel erklärt was ich erst einmal stehen hätte lassen können, ich werde das auf jeden Fall überdenken.

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.

Um noch aufs nicht Englisch können einzugehen, du hast recht man muss Englisch können doch im ersten Kapitel will der Leser nicht denken, er will ein Erfolgserlebnis und das so schnell wie möglich. Ansonsten gebe ich dir Recht.

Vielleicht werde ich nicht auf die ersten zwei Zeilen eingehen,
wäre eventuell besser so.

Danke an alle, habt mir sehr geholfen.

Sgt. Nukem

Einige Fackten zu C++:

*gallewiederrunterschluck*

Ich habe mir jetzt mal vorgenommen das ganze mehr zu splitten, zu fast jedem Abschnitt wird es einige Aufgaben + Lösungen geben:

Intro
Was kann C++ und warum C++ lernen
Ein bisschen Geschichte
Einrichten einer Entwicklungsumgebung ( (Windows VC + Dev-C++) +(Linux KDevelop) )
Das Erste Programm (Bildschirmausgaben etc.)
Variablen + Stringklasse der STL(Eingaben aus der Tastatur einlesen und speichern)
Kontrollstrukturen
Zeiger
Funktionen

Das sollte für den Anfang reichen... ich melde mich dann bald wieder.
Danke an alle.

TeeJay

Hi.

Ich finde "leider" machst du (wie auch sehr sehr viele) den bösen Fehler zu weit vorne zu beginnen.

Programmieren ist ein bisschen mehr als nur das eintippen von "einfachen" Befehlen.

Gerade bei C/C++, wo man doch recht nahe an den Bits und Bytes arbeitet finde ich das das erste Kapitel sich mit den Datentypen und den Grundlagen der Speicherung von Zahlen, Buchstaben etc. in diesen befassen sollte.

Ich erlebe es gerade bei mir in der Vorlesung zu C Programmieren.
Mein Prof fängt genauso an wie du und kommt mit dieser Methode zwar sehr schnell zu Ergebnissen (sprich zum ersten fertigem Programm) aber verstehen tun es die Leute nicht. Die Fragen sich nämlich was denn eigentlich passiert wenn ich "int iZahl1;" da hinschreibe und warum ich das machen muss etc.
Und dann auch noch worin genau der Unterschied zwischen "int" und "unsigned int" besteht. Und dann WARUM ich bei "unsigned int" viel größere Zahlen darstellen kann als nur mit "int".

Ich finde GENAU DAS wird in SO vielen Tutorials einfach verschluckt! Und es ist absolut wichtig, gerade bei C/C++, dieses zu verstehen. Daher ist es vollkommen unangebracht im ersten Kapitel mit einem "Hello World" Programm anzufangen.

Das ist zwar nur meine Meinung, aber ich habe gesehen das es vielen Leuten genau so ergeht wie ich hier beschrieben habe.

Ich persöhnlich muss sagen, das ich in C/C++ wesentlich sicherer geworden bin, als ich auch noch mit Assembler angefangen habe, da ich nun genau weiß was denn intern vorgeht wenn ich da eine bestimmte Zeile in C verfasse.

Und wenn ich den Hintergrund der Bits und Bytes nichtmal verstehe oder weiß das es sowas gibt, brauch ich mit C nicht anzufangen.

Unix-Tom

Artchi schrieb:

Unix-Tom schrieb:

C++ ist die in der Proffesionellen Programmierung am meisten genutzte Sprache

Ich würde das auch nicht als Fakt hinstellen. Die meisten Betriebssysteme sind in C/ASS.

Aha? Und professionelle Programmierung wird nur in der Betriebssystem-Entwicklung betrieben???

Ist doch genau was ich gesagt habe. Sein Aussage stimmt nicht.
Wenn jemand sein Tut ließt, läuft derjenige dann herum und sagt: "Die Profis programmieren alle in C++ und das ist der Großteil der Entwickler"

Die ist kein Fakt da es nicht stimmt. In einem Tutorial soll man nicht Halbwahrheiten verbreiten, da ein Leser dies als gegeben annimmt.

Geht man jetzt von Großteil aus so wären es z.B. PHP,JAVA, etc.
Auch das Programmieren ein Website ist Programmieren. Dies geschieht aber nicht mit C++ sondern mit php,java und was weiß ich noch alles. Das darunter C arbeitet ist in diesem Fall irrelevant. Dies meinte ich mit Betriebssystem. Im Grunde programmieren auch php- und java-entwickler auch mit hilfe von c/c++. Die meisten Programme sind aber nicht C++.

Artchi

TeeJay! Muß dir hier voll und ganz zustimmen! Aber ich denke, das es heute schwieriger ist, in Assembler einzusteigen. Oder sagen wir es mal so: alle wollen Fenster usw. darstellen.

Damals hab ich auf dem C64 in Assembler angefangen. Ich wußte also wie so ein Computer arbeitet. Als ich dann Jahre später auf C++ umstieg (was mir seeehr schwer fiel!), habe ich mir bei jeder Zeile die ich eintippte, vorgstellt, was nun der Compiler daraus macht. Eigentlich war es verrückt sich jedesmal darüber Gedanken zu machen. Vorallem habe ich bei OO-Kram die Kriese bekommen, weil in meinen C++-Büchern nicht drin stand, was im Hintergrund passiert, wenn ich eine Klasse instanziere.

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." Ich konnte es mir einfach nicht vorstellen, was damit gemeint war. Ich habe noch in Assembler gedacht. Es sind nicht nur Einsteiger-Tutorials wo ich sowas vermisst habe.

Sicherlich, heute weiß ich was da passiert. Und ich kann heute beruhigt und bedenkenlos OO programieren.

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.

TeeJay

@Artchi

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.

TeeJay

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.

Shade Of Mine

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

Shade Of Mine

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.

Marc++us

Shade, ohne Kentnisse der Grundlagen von Bits und deren Operatoren passiert aber irgendwann sowas:

http://www.c-plusplus.net/forum/viewtopic.php?t=70607

TeeJay

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

Artchi

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

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

Jester

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

SirLant

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 fehlt

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

Shade Of Mine

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