Möchte C++ / programmieren lernen

asc

Xin schrieb:

Soll ich's kurz machen? Es ist uninteressant, und außer "virtual" wirst Du in C++ nix finden, was mit OOP zu tun hätte.
...
Wer sich jetzt berufen fühlt, groß aufzuschreien - und das werden viele sein - sollte vielleicht nicht nur "Fachliteratur" wie den Informatik-Duden und Wikipedia-Artikel lesen, sondern sich mal tiefergehend damit beschäftigen...

Ich glaube ich brauche mit dir wirklich nicht zu diskutieren, es ist ebenso sinnlos wie einigen zu Erlären das die Verwendung einer Klasse nicht automatisch OOP ist.

Und zur "tiefgreifenden Beschäftigung" mit der Materie:
Ich mag vermutlich nicht ganz so alt sein wie du es bist (ich bin nur 30), und mich auch noch nicht solange mit Programmierung und Softwareentwicklung beschäftigen (nur etwa 17 Jahre bzw. nur etwa 11 Jahre seit ich Beruflich damit zu tun habe), und ich habe auch kein abgeschlossenes Studium wo ich anderen sagen kann: Ich weiß die Ultimative Lösung.

Ich weiß das ich nicht allwissend bin und ich lerne stetig hinzu (ebenso wie meine Literatur stetig anwächst, auch wenn du recht hast: letztgenanntes Buch habe ich wirklich nicht) und ich merke noch heute jede Woche das es immer noch Dinge gibt die es zu lernen gibt. Aber ich betrachte nicht alleine C++ sondern auch Bücher die sich um Softwareentwurf (verschiedene Paradigmen), und im Speziellen um Objektorientierung und UML drehen [Und ja, auch ich habe mit der prozeduralen Programmierung angefangen].

Ich kenne auch die Entwicklung von C++ und auch das es sehr klein angefangen hat (grade was OOP angeht) und noch immer in der Weiterentwicklung ist.

Aber die Objektorientierung auf virtuel zu begrenzen, ja, da nehme ich mir heraus zu sagen das du keine Ahnung von OOP hast.

cu André

Xin

pale dog schrieb:

Xin schrieb:

...und außer "virtual" wirst Du in C++ nix finden, was mit OOP zu tun hätte.

klassen. irgendwo müssen die objekte ja herkommen...

Nopes, sorry, better luck next time. ^^

Structs oder Arrays reichen vollkommen.

pale dog

Xin schrieb:

pale dog schrieb:

Xin schrieb:

...und außer "virtual" wirst Du in C++ nix finden, was mit OOP zu tun hätte.

klassen. irgendwo müssen die objekte ja herkommen...

Structs oder Arrays reichen vollkommen.

siehste, dann hat c++ schon 3 OOP features

otze

Weis ja nicht, ob das diskutieren mit Xin soviel sinn hat.

Ja, es ist richtig dass man zuerst if lernen muss, aber dafür brauch man beileibe kein C buch für. Aber bevor man sich mit den CStrings, printf und dynamischen arrays rumschlägt, kann man gleich std::string, std::vector und die iostreams verwenden. Und wenn man früh lernt, dass man probleme mit den stl algorithmen lösen kann, dann ist man auch ein großes stück weiter und lernt gleichzeitig ein paar wichtige Sachen über die Art, wie man heutzutage C++ programmiert.

Btw: 2 der 3 oben genannten Klassen benutzen nichtmal virtual in irgendeiner Form. Da dies aber scheinbar keine OOP nach deiner definition ist, aber ein unbestritten wichtiger bestandteil von C++, wankt deine Theorie C++ = C mit Klassen mal ganz stark. QED. Übrigens könnte man das auch meinen, weil C++ eben nicht C mit Klassen heisst. Und wenn man sich anschaut, was in den nächsten Standard alles reingenommen wird weil es nötig erscheint, und das alles keine OOP features sind, kommt man auch ins Grübeln, und Stroustrup macht da sogar ordentlich mit

und zuguter letzt: OOP!= vererbung. Es kommt einzig und allein darauf an, dass man daten und methoden die zusammengehören zusammenschriebt. Die C filestreams sind zb gute oop, nur dass es dort das class schlüsselwort nicht gibt.

Xin

asc schrieb:

Xin schrieb:

Soll ich's kurz machen? Es ist uninteressant, und außer "virtual" wirst Du in C++ nix finden, was mit OOP zu tun hätte.
...
Wer sich jetzt berufen fühlt, groß aufzuschreien - und das werden viele sein - sollte vielleicht nicht nur "Fachliteratur" wie den Informatik-Duden und Wikipedia-Artikel lesen, sondern sich mal tiefergehend damit beschäftigen...

Ich glaube ich brauche mit dir wirklich nicht zu diskutieren, es ist ebenso sinnlos wie einigen zu Erlären das die Verwendung einer Klasse nicht automatisch OOP ist.

Das würde nicht viel bringen, da ich bereits vorher gesagt habe, dass ausschließlich "virtual" OOP ist. Von Klassen habe ich nichts gesagt, die brauchst Du für OOP auch nicht.

asc schrieb:

Und zur "tiefgreifenden Beschäftigung" mit der Materie:
Ich mag vermutlich nicht ganz so alt sein wie du es bist (ich bin nur 30), und mich auch noch nicht solange mit Programmierung und Softwareentwicklung beschäftigen (nur etwa 17 Jahre bzw. nur etwa 11 Jahre seit ich Beruflich damit zu tun habe), und ich habe auch kein abgeschlossenes Studium wo ich anderen sagen kann: Ich weiß die Ultimative Lösung.

So alt bin ich auch noch nicht, auch erst 30.
Ich habe aber schon mehrfach C/C++ unterrichtet und Compilerbau und Sprachdesign zog sich als roter Faden durch mein Studium. Ich kenne einiges an Literatur dazu und schreibe selbst einen Compiler.
Anders ausgedrückt: Das hier ist exakt das Thema, in dem man sehr schwer Argumente finden wird, die ich noch nicht kenne. Diskutier mir mit über OpenGL, da habe ich im großen ganzen keinen Plan von, das erhöht Deine Chancen mit Halbwissen Recht zu bekommen erheblich.

asc schrieb:

Ich weiß das ich nicht allwissend bin und ich lerne stetig hinzu (ebenso wie meine Literatur stetig anwächst, auch wenn du recht hast: letztgenanntes Buch habe ich wirklich nicht)

War zugegebenermaßen ein Totschlagargument. Das Buch kennt keine Sau, aber die wenigsten wollen auch wissen, warum C++ so ist, wie es ist.

Das Buch wird von AW nicht mehr verlegt, es ist auch keine Neuauflage geplant. Ich habe meins bei EBay gekauft, nach 6 Monaten Suche, verkaufte mal jemand ein Exemplar.
Es ist allerdings auch nicht mein Job, jemandem der es offenbar besser als ich weiß, Informationen zuzuspielen.

Informatiker sind diejenigen, die das "Warum?" ihrer Werkzeuge am wenigsten hinterfragen. Es ist da, es tuts, ich weiß nicht warum, aber solange ich so Geld verdiene ist doch alles im Butter.

asc schrieb:

Ich kenne auch die Entwicklung von C++ und auch das es sehr klein angefangen hat (grade was OOP angeht) und noch immer in der Weiterentwicklung ist.

Aber die Objektorientierung auf virtuel zu begrenzen, ja, da nehme ich mir heraus zu sagen das du keine Ahnung von OOP hast.

Aufgrund der vorherigen Auskunft lernbereit zu sein, testen wir das doch mal an und ignorieren die Zuschreibung besonderer Kompetenz. ^^

Den Fehler, den die meisten Programmierer machen ist, dass sie glauben, in C könnte man nicht OOP programmieren, in C++ schon. Daraus wird geschlussfolgert, dass das, was C++ mehr kann, das ist, was OOP ausmacht.
Weil die Leute nicht wissen, wie es wirklich funktioniert, mystifizieren sie es und machen da irgendwas großes, tolles, wichtiges draus. Weiterhin ist OOP ein Marketing-Begriff. OOP ist modern. Die Programme werden aber trotzdem nach Assembler kompiliert, es steckt keine Magie dahinter.

Objektorientierte Programmierung bedeutet, dass Du ein Datenobjekt hast - und das muss keine Klasse sein, es reicht vollkommen aus, wenn es einfach nur ein paar Bytes hintereinander sind - und dieses Datenobjekt führt die Information mit sich, was es ist, also zum Beispiel Dreieck oder Rechteck.

Das wird in der Regel so realisiert, dass das Objekt einen zusätzlichen Zeiger auf die Typinformation bekommt. In C++ wird dieser Zeiger mitgegeben, sobald die erste virtuelle Funktion ins Spiel kommt. Wenn Dein Compiler also meldet, dass er nicht weiß, wo er die vtable unterbringen soll, dann ist das genau diese Typinformation, der GCC koppelt sie an den Destruktor. Virtuelle Funktionen ohne Destruktor gibt Ärger.
Das kannst Du leicht testen, in dem Du sizeof() für eine Klasse ohne virtuelle Funktion aufrufst und ein sizeof() mit beliebig vielen virtuellen Funktionen. Das Objekt mit virtuellen Funktionen enthält nicht mehr Daten ist aber genau eine Zeigerlänge größer (also i.d.R. 4 bzw. 8 Byte).

Überlädst Du eine Funktion, so wird die Funktion aufgerufen, entsprechend ihres Datentyps.

class Figur
{
  double GetAreaSize();
  virtual double GetAreaSize_virtual();
};

class Rect : public Figur { ... };
class Triangle : public Figur { ... };

Hast Du eine nun eine Variable vom Typ Rect in einem Zeiger vom Typ Figur und rufst GetAreaSize() so wird Figur::GetAreaSize() gerufen. Das ganze ist statisch an den Datentyp geknüpft.

Rufst Du GetAreaSize_virtual(), so wird auch Figur::GetAreaSize_virtual() gerufen. In dem Fall wird allerdings der Funktionsaufruf über die Typinformation geleitet. Die Typinformation enthält ein Array mit Funktionszeigern für alle virtuelle Funktionen. Der Datensatz enthält hier einen Zeiger auf die Typinformation "Rect" und dort steht auch, wo die Funktion Figur::GetAreaSize_virtual() zu finden ist. Darum ist der Ruf von virtuellen Funktionen auch immer teurer als von statischen.

Für den Datensatz - das Objekt - vom Typ "Rect" zeigt dieser Funktionszeiger also woanders hin als, als wäre es ein Objekt vom Typ "Triangle". Der Funktionsaufruf ist nicht statisch, sondern vom Objekttyp abhängig, anders ausgedrückt: Objekt orientiert.

Das ist objektorientierte Programmierung. Das wars, mehr ist es nicht.

Vererbung ist ein ganz anderes Konzept, das funktioniert auch auch bei statischen Überladungen. Das gleiche gilt für Data-Hiding. Das hat alles mit OOP nichts zu tun, sondern sind vollkommen statische Techniken.

Ich mag zwar keine Ahnung haben, aber Du kannst das bei Bedarf bei Stroustrup nachlesen. Wie wir bei "C mit Klassen" festgestellt haben, hat der aber auch keine Ahnung.

Ich muss ganz ehrlich sagen, wenn das ganze Forum der Meinung ist, dass ich keine Ahnung habe, dann habe ich da kein Problem mit. Ich lese ja auch nicht die Bildzeitung.

Artchi

Wenn jemand C++ lernen will, dann will er auf eine bestimmte Art und Weise ein Problem lösen. Und dann soll er/sie auch C++ und nicht C lernen. Ganz einfach. Denn letztendlich ist das Erlernen von C für C++ völlig nutzlos. Denn wenn ich jemandem C beibringe, bringe ich ihm eine bestimmte Philosophie des Denkens und Programmierens bei. Und das ist nich das gleiche Ziel wie C++. C++ wurde entwickelt, weil man mit der Denkweise und Programmierung von C nicht einverstanden war, um ein Problem zu lösen. Hätte Stroustrup damals mit C voll und ganz zufrieden sein können für seine Problem, hätte er nicht C++ entwickelt. Er hat einen Bedarf festgestellt, den C nicht abdecken kann.

Das C zum großen Teil (noch nicht mal 100%!) in C++ steckt, ist ein reiner Marketinggag. Weil man damit die C'ler mit ihren Projekten nach C++ locken konnte. Also eine Migration erleichtert hat. Mehr auch nicht. Und sind wir ehrlich, der Trick hat funktioniert.

Wenn jemand fragt "Wie kann ich C++ lernen?" ist es einfach falsch zu sagen "Lern C!". Das ist NICHT die Antwort die er hören wollte und soll. Wenn jemand wissen will, wie man Brötchen backt, sage ich ihm auch nicht "Ich gib dir ein Backrezept wie man ein Brot backt.". Was ist das für eine Hilfe? Keine!

pale dog

Artchi schrieb:

...man damit die C'ler mit ihren Projekten nach C++ locken konnte. Also eine Migration erleichtert hat. Mehr auch nicht. Und sind wir ehrlich, der Trick hat funktioniert.

das glaubst aber nur du

Xin

Artchi schrieb:

Hätte Stroustrup damals mit C voll und ganz zufrieden sein können für seine Problem, hätte er nicht C++ entwickelt. Er hat einen Bedarf festgestellt, den C nicht abdecken kann.

Ähhh... auch hier muss etwas einspruch erheben.

Er schrieb ein Projekt in Simula, doch das war zu langsam, also wollte er es in C neu schreiben. OOP ist in C aber nicht so schön, also schrieb er Makros. Um das nochmals zu verdeutlichen, er schrieb Makros, nicht "C mit Klassen". Das Projekt nannte sich Cfront und wurde über Jahre gepfegt. Die ersten C++-Programme wurden mit C-Compilern kompiliert. Anders ausgedrückt: C wurde dem Bedarf gerecht.
Nach etwa 5 Jahren Cfront, entstand der erste "C mit Klassen"-Compiler, der zu C++ umbenannt wurde.

Artchi schrieb:

Das C zum großen Teil (noch nicht mal 100%!) in C++ steckt, ist ein reiner Marketinggag. Weil man damit die C'ler mit ihren Projekten nach C++ locken konnte. Also eine Migration erleichtert hat. Mehr auch nicht. Und sind wir ehrlich, der Trick hat funktioniert.

Interessante Formulierung.
C ist zum großen Teil in C++, wenn auch nicht zu 100%, ist kein Marketing-Gag, sondern eine Tatsache. Die Begründung ist allerdings korrekt, war allerdings kein als Trick gedacht, sondern als Einladung, so dass man Schritt für Schritt auf C++ wechseln konnte.

Artchi schrieb:

Wenn jemand fragt "Wie kann ich C++ lernen?" ist es einfach falsch zu sagen "Lern C!". Das ist NICHT die Antwort die er hören wollte und soll.

Hier drehen wir uns im Kreis. Du gehörst zu den Leuten, die eine Anfänger mit Möglichkeiten erschlagen und ich gebe ihnen einen Laufstall, wo sie laufen lernen. Danach können sie immernoch zu C++ wechseln.
Was sich innerhalb einer Klasse abspielt ist nahezu reines C.

Ich denke, meine Methode zu unterrichten war recht erfolgreich und effektiv, das wurde mir von den Studenten auch so bestätigt.

.filmor

Xin schrieb:

Ich denke, meine Methode zu unterrichten war recht erfolgreich und effektiv, das wurde mir von den Studenten auch so bestätigt.

Dann karr' mal einen von denen hier an

Im Ernst, C++ ist grundsätzlich keine Anfängersprache, da gibt's viele sehr viel besser geeignete. Aber wenn man schon C++ lernen will, dann sollte man das imho auch ganz unabhängig von C lernen denn es sind zwei verschiedene Sprachen (die natürlich beide gleich mächtig sind, aber unterschiedliche Ansätze zur Problemlösung erfordern).
Und allgemein würde ich eher die generische Programmierung als Hauptvorteil von C++ gegenüber C herausheben, nicht die Objektorientierung (die zwar vergleichsweise marginal aber dennoch ausreichend vorhanden ist). Mit Templates zu programmieren ist vergleichsweise schwer, aber an praktisch keiner Stelle benötigt man dazu C.

Xin schrieb:

Er schrieb ein Projekt in Simula, doch das war zu langsam, also wollte er es in C neu schreiben. OOP ist in C aber nicht so schön, also schrieb er Makros. Um das nochmals zu verdeutlichen, er schrieb Makros, nicht "C mit Klassen". Das Projekt nannte sich Cfront und wurde über Jahre gepfegt. Die ersten C++-Programme wurden mit C-Compilern kompiliert. Anders ausgedrückt: C wurde dem Bedarf gerecht.
Nach etwa 5 Jahren Cfront, entstand der erste "C mit Klassen"-Compiler, der zu C++ umbenannt wurde.

Woah?! Das sieht die Wikipedia etwas anders. Und bevor du mir jetzt mit deiner "ich mach das schon ewig"-These kommst, weist du mir erstmal mit geeigneten Zitaten nach, dass das so nicht stimmt (zB das Cfront einen eigenen Parser hatte, was so ganz und gar nicht mit deiner Makrobehauptung zusammenpasst). Desweiteren wird auch C in Assembler übersetzt, also wäre das genauso ausreichend. Wird es deshalb dem Bedarf gerecht? (Und um direkt die Plattformabhängigkeit zurückzuweisen, es spricht nichts dagegen, eine C-ähnlich plattformunabhängige Assemblersprache zu entwickeln.)

Xin schrieb:

Artchi schrieb:

Wenn jemand fragt "Wie kann ich C++ lernen?" ist es einfach falsch zu sagen "Lern C!". Das ist NICHT die Antwort die er hören wollte und soll.

Hier drehen wir uns im Kreis. Du gehörst zu den Leuten, die eine Anfänger mit Möglichkeiten erschlagen und ich gebe ihnen einen Laufstall, wo sie laufen lernen. Danach können sie immernoch zu C++ wechseln.
Was sich innerhalb einer Klasse abspielt ist nahezu reines C.

Toll. Und was bringt das? Du kannst so viele Ebenen runter gehen wie du willst (auch wenn es nach C zugegebenermaßen nicht mehr viele gibt). Es ist gut für einen Programmierer, wenn er weiß was abläuft. Deine Methode wäre konsequent, wenn du zu erst Maschinensprache, dann Assembler und danach C beibringen würdest. Ich für meinen Teil halte die andere Richtung für sinnvoller, die sich quasi automatisch aus dem jedem Programmierer zugehörigen Optimierungsdrang entwickelt.

*Wäre schon wenn ein Mod dazu in der Lage wäre den Thread zu splitten und in RUDP verschieben könnte*

Xin

.filmor schrieb:

Xin schrieb:

Er schrieb ein Projekt in Simula, doch das war zu langsam, also wollte er es in C neu schreiben. OOP ist in C aber nicht so schön, also schrieb er Makros. Um das nochmals zu verdeutlichen, er schrieb Makros, nicht "C mit Klassen". Das Projekt nannte sich Cfront und wurde über Jahre gepfegt. Die ersten C++-Programme wurden mit C-Compilern kompiliert. Anders ausgedrückt: C wurde dem Bedarf gerecht.
Nach etwa 5 Jahren Cfront, entstand der erste "C mit Klassen"-Compiler, der zu C++ umbenannt wurde.

Woah?! Das sieht die Wikipedia etwas anders. Und bevor du mir jetzt mit deiner "ich mach das schon ewig"-These kommst, weist du mir erstmal mit geeigneten Zitaten nach, dass das so nicht stimmt (zB das Cfront einen eigenen Parser hatte, was so ganz und gar nicht mit deiner Makrobehauptung zusammenpasst).

Dafür muss ich nichts 'ewig' machen. Wenn Stroustrup schreibt, dass er Cfront mit dem C-Präprozessor realisiert hat, dann ist mir die Sichtweise der Wikipedia eigentlich ziemlich egal: Das Buch heißt "Design und Entwicklung von C++", dort gibt es ein ausführliches Kapitel über Cfront.
Solltest Du mir nicht glauben, empfielt sich ein Besuch in Deiner Bibliothek.
Dass es später effizientere Cfront-Parser und Compiler, die dann "C mit Klassen"- oder "C++"-Compiler getauft wurden, ist bekannt und ändert nicht daran, dass die erste Version von C++ in C entstanden ist.

Zu allem anderen gibt es bereits Statements in diesem Thread von mir.

"Ein neuer 3D-Motor wurde eigens für dieses Spiel entwickelt. Er benutzt DirectX8 und ist geeignet, grossräumige Landschaften darzustellen. Folgende Technologien wurden implementiert:"

http://colobot.com/colobot/technic-d.php

L O L

Xin

Ich habe nachgeguckt, es handelte sich nicht um den C-Präprozessor, zumindest finde ich auf die Schnelle kein Zitat dazu. Ich habe in Erinnerung, dass er 1978 mit Makros begann, ich habe allerdings jetzt auch keine Lust die ganze Einleitung wieder lesen. Daher folgende Korrektur: Er schrieb vor Cfront einen eigenen Präprozessor.

"Im Oktober 1979 hatte ich einen lauffähigen Präprozessor mit dem Namen 'Cpre' geschrieben, der C um Simula-ähnliche Klassen erweitert. Bis März 1980 so weit verbessert, dass er für ein Projekt und mehrere Experimente eingesetzt werden konnte. [...] Der Grundstock einer ersten Bibliothek für C++. [...] Die durch den Präprozessor festgelegte Sprache nannten wir 'C mit Klassen'." (Entwicklung von C und C++, Bjarne Stroustrup, Seite 33f)

"Cfront wurde von mir zwischen Frühling 1982 und Sommer 1983 entworfen." (Seite 83).

'Cpre' habe ich wie es aussieht mit 'C-Preprocessor' verwechselt. Mea maximal culpa: es ändert allerdings nichts daran, dass er nach C übersetzte. C++-Codes wurden über den C-Compiler kompiliert und es begann mit einem Präprozessor.
Da er lediglich Cpre statt cpp benutzte, ändert ansonsten aber nichts.

Artchi

Na und? Eifel übersetzt auch erst nach C oder C++. Was hat aber Eifel jetzt mit C oder C++ zu tun? Nichts! Was hat eine zwischenstufige Übersetzung mit dem erlernen einer Sprache zu tun? Nichts! Wenn ich Java lerne, dann lerne ich auch nicht vorher den Bytecode der JVM kennen. Weil völlig sinnlos und irrelevant.

Und ich frage dich nochmal: Warum hat er die ganzen Tools, wie CFront entwickelt? Weil er mit seinen bisherigen Tools voll zufrieden war??? Nein, sicherlich nicht. Ich entwickle/erfinde etwas, wenn mir das aktuell vorhandene nicht genügt. So einfach ist das.
Den Zwischencode hat er nur benutzt, damit er sich die Programmierung eines C++-Compilers erspart. Reine Kosten- und Zeitfrage gewesen. Nichts anderes machen Sprachen wie Eifel: aus reinen Kostengründen erspart man sich den Bau eines echten Eifel-Compilers. Ich bezweifel mal, das aber Eifel irgendwas mit C am Hut... genau das gleiche bei C++: der CFront von damals ist heute sowas von piep egal, das ist Geschichte und das sollte es auch bleiben.

MilchMaedchen

Hey!

Die Sprache ist schon nicht ganz leicht, am besten ist sie zu verstehen wenn man schon eine Sprache kann, z.B. Java. Aber ich habe festgestellt, dass es sich aus Büchern ganz schwer lernen lässt, hilfreich sind sie zwar, aber manchmal ein wenig zu schnell erklärt. Eine Möglichkeit ist, wenn du bei Google mal nach Vorlesungsscripte von Unis oder Hochschulen suchst, die sind meistens selbsterklärend, außerdem gibt es Unmengen von Tuts im Internet die alles wichtige Schritt für Schritt erklären und jedes Kapitel mit einer Beispieldatei abschließen.

Viel Glück ...

Xin

Artchi schrieb:

Na und? Eifel übersetzt auch erst nach C oder C++. Was hat aber Eifel jetzt mit C oder C++ zu tun? Nichts! Was hat eine zwischenstufige Übersetzung mit dem erlernen einer Sprache zu tun? Nichts!

Eiffel ist weder Ober- oder Untermenge von C oder C++ und hatte niemals die Intention dazu.
Zwischen C und C++ erkennst Du aber doch eine Verwandtschaft, oder? Das hat etwas mit dem Erlernen einer Sprache zu tun.

Ansonsten wird Eiffel mit zwei 'f' geschrieben, aufgrund von Gustave EifFel, dem Erbauer des EifFelturms, auch wenn Gustaves Name ursprünglich auf die Eifel (ein F) bezogen war, so schreibt er sich dennoch mit zwei 'F'.

Artchi schrieb:

Und ich frage dich nochmal: Warum hat er die ganzen Tools, wie CFront entwickelt? Weil er mit seinen bisherigen Tools voll zufrieden war??? Nein, sicherlich nicht. Ich entwickle/erfinde etwas, wenn mir das aktuell vorhandene nicht genügt. So einfach ist das.

Wenn Stroustrup keine Vorteile in C gesehen hätte, wäre C heute keine Teilmenge von C++. Auf haarspalterische Diskussionen, dass der aktuelle Standard ein paar Datentypen mitbringt, die der C++-Standard noch nicht hat, brauchen wir uns doch jetzt einzulassen, oder?

Wenn keiner hier Vorteile sieht, die ersten Gehversuche in einem übersichtlichen Laufstall zu machen, dann ist den Schülern auch nicht mehr zu helfen - eine nicht geringe Menge wird sich verlaufen.
Im Tutorium hatte ich sie ja da und durfte sie wieder einfangen. Die meiste Arbeit im Tutorium war es, die Vorstellungen zu begreifen und auszutreiben, die sich die Studenten mit ihrem Halbwissen angegeignet haben, weil sie beim Erlernen der vielen Möglichkeiten vollkommen die Übersicht verloren haben.
Dann fängt man wirklich noch mal bei Null an und geht Schritt für Schritt Grundlagen durch und später kommt man dann auch wieder bei OOP an.
Die zwei Semester zuvor waren diesbezüglich vorrangig Zeitverschwendung, sie behinderten das Lernen sogar massiv, die Studenten kamen teils mit absolut wirren Vorstellungen ins Tutorium, die man erstmal selbst nachvollziehen muss, um zu erklären, warum die Vorstellung nicht zutrifft. Das ist, als bekommt man die Rotation der Planeten hochgradig kompliziert erklärt und wundert sich, was die sich da ausgedacht haben, bis die Rotation der Sonne um die Erde erklärt bekommt und verstanden hat, was man in der Vorstellung korrigieren muss.
Wissen, das Dir und mir selbstverständlich erscheint, weil es eben Grundlagen sind - Grundlagen, die diese Leute eben nicht haben. Ich hätte mal Buch führen sollen über die Ideen auf die die Leute teils kamen.
Schüler ohne OOP-Vorwissen lernten deutlich schneller und können mit OOP anschließend besser umgehen, weil sie wissen, warum sie OOP verwenden. Sie lernen die Funktionsweise der Sprache und entwickeln keine mystischen Vorstellungen, in der Regel entstehen nur kleine Missverständnisse, die mit ein, zwei Sätzen erklärt sind binnen weniger Minuten erklärt sind.

Artchi schrieb:

Der CFront von damals ist heute sowas von piep egal, das ist Geschichte und das sollte es auch bleiben.

Nanana, Cfront ist der Übergang von C auf C++, mehr habe ich hier nicht geschrieben. Solltest Du hier andeuten, dass Cfront nun als Lernstoff für Anfänger nach C gelten soll, dann lies, was ich schreibe. Niemand will Cfront in die Gegenwart holen.

Nichtsdestotrotz ist der Prozess des Begreifens von Konzepten über die Sprachgenerationen ablesbar. Den Weg wird jeder von uns beschreiten müssen. Sie wurden aufeinander aufbauend entwickelt, weil sich das Verständnis weiterentwickelte.
Wer am Ziel anfängt, dem fehlen die Grundlagen.
Das bedeutet nicht, dass man Assembler perfekt können muss, um C zu lernen. Es schadet aber nicht, sich mit dem Prozessor auseinander zu setzen. Und genauo hilft es, sich mit C auseinander zu setzen, um C++ zu lernen.

Wenn ihr der Überzeugung seid, dass es sinnvoll ist, die Grundlagen später mal zu verstehen, habe ich da eigentlich wenig Probleme mit, solange ihr nicht mit mir an einem Projekt arbeitet und ich laufend den Erklärbär auspacken muss.

asc

Xin schrieb:

Schüler ohne OOP-Vorwissen lernten deutlich schneller und können mit OOP anschließend besser umgehen, weil sie wissen, warum sie OOP verwenden. Sie lernen die Funktionsweise der Sprache und entwickeln keine mystischen Vorstellungen, in der Regel entstehen nur kleine Missverständnisse, die mit ein, zwei Sätzen erklärt sind binnen weniger Minuten erklärt sind.

Das wiederspricht meiner Erfahrung, liegt aber vielleicht auch immer daran WIE etwas erklärt wird und nicht daran WAS erklärt wird. Ich hatte mal ein paarmal eine größere Gruppe von Auszubildenden zu betreuen. Als ich reinkam war die Situation die, das von 25 Leuten nur 3 weitermachen wollten weil die anderen an C++ scheiterten. Und nach dem ich ein paarmal da war (und ja, ich habe mit Grundsätzen der Objektorientierung nicht der Sprache angefangen) sah das Verhältnis genau andersrum aus, und mir wurde mitgeteilt das dies zum großen Teil meinen Erklärungen zuzuschreiben war.

Aber nochmal einen Schritt zurück: Es ist für das Verständnis wenn man eine Sprache xyz lernen will nicht hilfreich wenn man im ersten Moment weiß das der Compiler daraus erst etwas in der Sprache yz macht. Um genau zu sein: Was interessiert es im ersten Moment einen Anfänger. Die Details kann man später noch lernen wenn man die Grundsätze der Sprache versteht.

Wenn man Objektorientierung richtig erklärt entspricht sie der menschlichen Denkweise weit mehr als die prozedurale Denkweise. Wir Menschen vereinfachen Sachbestände auch in dem wir sie auf ein wesentliches runterreduzieren und Klassifizieren. Wenn jemand von einen Haus spricht muss er nicht groß erwähnen was er meint, wir haben alle eine Vorstellung davon (selbst wenn es unterschiedliche Häuserformen gibt, geht es erstmal darum jemanden das wesentliche rüberzubringen).

Davon abgesehen, mag alles mit C mit Klassen begonnen haben, wir sind aber nicht mehr in den Stand als dieses frühe C++ existiert hat.

Soll ich die Geschichte weiter aufrollen?

Ende der 80er Jahre wurde zunächst ein "C mit Klassen" entwickelt, später wurde der Name C++ übernommen um darzustellen das es eine weiterentwicklung der Sprache C war. Die Objektorientierung als Solche steckte in der damaligen Zeit noch in den Kinderschuhen und demzufolge war die Umsetzung der Objektorientierung noch recht dürftig und in der Entwicklung. Mit dem Fortschritt der Entwicklung des Objektorientierten Begriffes als solches wurde auch C++ weiterentwickelt. Im wesentlichen sind hier die Versionen 1.0,1.1,2.0,2.1 und 3.0 des AT&T Standards zu nennen (die aktuelle Standardimplementierung wurde cfront genannt).

1.0: C++ bekommt die Sprachmerkmale die zum Kapseln von Daten und der Funktionsüberladung nötig waren (Datenkapselung und Überladung gehört zu OOP), zu der Zeit diente die Vererbung noch dem Ansammeln von Daten und Funktionalität.

2.0: virtual hielt einzug in die Sprache (Polymorphie gehört zu OOP)

3.0: rein virtuelle Funktionen wurden möglich und ermöglichten Klassen als reine Schnittstellen zu entwickeln.

Die Versionen die danach kamen dienten kaum mehr dazu etwas vom OO-Paradigma zu erweitern, sondern gingen in Richtung anderer Sprachparadigmen (z.B. Templates).

Du hast in einen Punkt recht als ich sagte das virtuell nur ein kleiner Teil von OOP, habe ich das etwas überspitzt. Ja die Polymorphie ist ein wichtiger Teil, aber ebenso sind auch Dinge wie Datenkapselung, Überladung... wichtig, die zusammen die Objektorentierten Grundzüge bilden. Und ist ja schön das du 2 Bücher aufführst, aber les dir bitte auch OO Bücher durch. Dort ist ebenso zu übernehmen das Polymorphie eben NICHT alles ist. Und ja mir ist klar das der Compiler intern anders arbeitet als nach außen hin, aber man entwickelt nicht gegen den Compiler (die Implementierung) sondern gegen die Schnittstelle (hier die Sprache).

cu André

Boa Ihr müssts ja foll die provies sein so wie ihr alles wisstz was man lernen muss.

Hallo

Xin schrieb:

chrische5 schrieb:

Wenn ich ein Haus bauen müsste würde mich der Prozess wie die Ziegel nun hergestellt werden auch nicht im ersten Moment interessieren...

Nicht alles, was hinkt ist ein Vergleich. Ein A380-Pilot muss das Flugzeug auch nicht herstellen, aber trotzdem kleinere Flugzeuge fliegen können.
Als Häusle-Bauer wirst Du erst kleine Häuser bauen, bevor Du die Petronas-Towers nachbaust.

Mach Dir nichts draus, ein Versuch war's wert. ;-D

Zitate zuordnen und dabei schlampen, geht ja nun gar nicht. Ich lege dir auch nicht einfach irgendwelche Dinge in den MUnd. Da sollte man schon aufpassen.

chrische

Artchi

Xin schrieb:

Wenn Stroustrup keine Vorteile in C gesehen hätte, wäre C heute keine Teilmenge von C++.

Hab ich schon gesagt: nur damit die C-Projekte nach C++ einfacher migriert werden können. Einen anderen Grund kann es für C nicht gegeben haben, wie der Erfinder der Sprache selbst in seinem Buch schreibt:

Bjarne Stroustrup in <Die C++ Programmiersprache, §1.4> schrieb:

C++ wurde hauptsächlich entworfen, damit meine Freunde und ich nicht in Assembler, C oder verschiedenen anderen modernen High-Level-Sprachen programmieren mußten. Das Hauptziel war, das Schreiben guter Programme für einzelnen Programmierer leichter und weitaus angenehmer zu gestalten.

Also ich interpretiere nicht gerade daraus, das C es einem einfacher oder verständlicher macht. Ganz im Gegenteil: er wollte kein C mehr.

Und das §1.6 zeigt nochmal deutlich, das C-Kompatibilität ein notwendiges Übel war und nicht weil er so geil auf C ist.

Bjarne Stroustrup in <Die C++ Programmiersprache, §1.6> schrieb:

Als C++ sich immer weiter verbreitete ... tauchte immer wieder die Frage auf, ob die Kompatibilität zu C beibehalten werden soll. Einige Probleme hätten ganz klar vermieden werden können, wenn einiges aus dem C-Erbe nicht übernommen worden wäre.

Danach führt er auf, warum C weiter ein Teil von C++ bleiben muß. Mio. Zeilen C-Code existiert, der von C++ profitieren kann. Und das Mio. C-Bibliotheksfunktionen existieren und diese von C++ aus genutzt werden können. Halt die Migration von C nach C++ leichter fällt. Und man bei C++-Projekten nicht bei null anfangen mußte, weil man schon viel Geld in C-Projekte investiert hat. Aber was hat ein Programmiereinsteiger mit bestehenden C-Projekten am Hut? Nichts! Er hat keine Zeit und Geld in C-Projekte investiert.

Und jetzt kommt das wichtigste für diesen Thread:

Bjarne Stroustrup in <Die C++ Programmiersprache, §1.6> schrieb:

C-Kenntnisse sind keine Voraussetzung, um C++ zu lernen. Das Programmieren in C erfordert viele Techniken und Tricks, die sich durch C++-Sprachmittel als unnötig erweisen.

So, wer immer noch der Meinung ist, das man für C++ C-Kenntnisse benötigt, sollte an Bjarne Stroustrup eine Mail schreiben und ihn auf seinen Fehler in seinem millionenfach verkauften Buch hinweisen und ihn belehren.

Am Ende glaube ich eher einem Bjarne Stroustrup als einem Xin. :p