Ich programmiere schon seit ein paar Jahren C und wrüde sagen, dass ich auch ganz gut darin bin. Dieses Semeser habe ich eine C-Lehrveransatung mit der Höchstunktezahl abgeschlossen und habe nächstes Semester gibt es die Möglichkeit dass ich eine Lernveranstaltung in der man C++ lernt als Freifach absolviere, das würde mich auch interessieren. Bevor ich nich dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie schwierig ihr es einshätzt C++ noch dazuzulernen. Danke für euere Meinungen.
:
Verschoben durch Admin
Die schlechte Nachricht: alles zu C++ lernen = keine Chance, das dauert ewig Die gute Nachricht: Man braucht von C++ nicht alles gleichzeitig, sondern kann sich stückweise rantasten. Also template-Funktionen, Operatoren überladen, OO, STL etc. kann man nacheinander angehen. Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen.
:
Bearbeitet durch User
Student schrieb: > Bevor ich nich > dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie > schwierig ihr es einshätzt C++ noch dazuzulernen. Der C++-Standard hat ca. 1500 Seiten. Ziemlich komplexe Syntax. Im Gegensatz zu C, behaupte ich, kann man diese Sprache niemals vollständig beherrschen. Scott Meyers - einer der heiligsten C++ Gurus - hat mal auf einer Konferenz gesagt, er wünscht sich eine Sprache, wo man Leute wie ihn nicht benötigt ;-) Er hat viele Bücher über die unendlichen Fallstricke verfasst. Lass dich bitte von den Uni-Klausuren und "Voller Punktzahl" nicht betrügen. Es ist war anderes in Großprojekt mit mehreren tausend Zeilen Code C wiederverwendbar zu beherrschen als ein paar Colaautomaten-Funktionen in einer 90-Minütigen Klausur zu tippseln.
c anteile findest du in c++ und c#. die sache ist, dass man in der regel nicht alles gleich gut beherrschen kann. kannst du das eine gut, wird das andere etwas verdrängt. c sollte man für den embedded bereich beherrschen und c++ oder c# für den pc bereich für objektorientierte programmierung. besuche den c++ kurs. egal ob schwer oder leicht. die sprachen sind nur werkzeuge. je besser du ein werkzeug beherrscht, desto besser für dich und dein produkt.
Klaus Wachtler schrieb: > Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen Als ob, das ist noch schön einfach und leicht vorstellbar. Warum immer alle Angst vor OOP haben verstehe ich nicht. Auch viele C-Programme verwenden OOP, und man kann auch C++ ohne OOP nutzen. Viel spaßiger als OOP ist die "richtige" Template/Meta Programmierung, Speicherverwaltung, rvalue references, korrekte Exception Sicherheit bei Meta Programmierung... Allerdings sollte das natürlich nicht abschrecken, C++ zu lernen - diese fortgeschrittenen Dinge braucht man nicht um schöne Anwendungen zu programmieren, und im Endeffekt kann man mit C++ schnell und effizient programmieren. Auch allgemein lohnt es sich über den C-Tellerrand zu blicken, und neue Programmierparadigmen zu lernen.
kaese schrieb: > Der C++-Standard hat ca. 1500 Seiten. Ziemlich komplexe Syntax. > > Im Gegensatz zu C, behaupte ich, kann man diese Sprache niemals > vollständig beherrschen. Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen... ;-)
Ratgeber schrieb: > Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird > hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen... Das ist nicht wahr. Niemand hat das je verlangt. Noch nichtmal hier.
Klaus Wachtler schrieb: > Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen. Das allein würde mir schon arg zu denken geben ob diese Denkweise der Weisheit letzter Schluß ist. Das Werkzeug sollte sich dem Menschen anpassen, nicht umgekehrt.
Das beste Buch dafür: http://www.amazon.de/C-Objektorientiertes-Programmieren-von-Anfang/dp/3499600773/ref=sr_1_5?ie=UTF8&qid=1422906504&sr=8-5&keywords=c%2B%2B
Student schrieb: > Bevor ich nich > dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie > schwierig ihr es einshätzt C++ noch dazuzulernen. Ich vermute dahinter versteckt sich "Objektorientiertes Programmieren am Beispiel C++". Objektorientiertes Programmieren (wie strukturiere ich ein Programm in getrennte Einheiten die einen) lohnt sich, das Konzept ist aber nicht auf C++ beschränkt. Gibt allerdings ein paar Kopfnüsse zu knacken. C++ selber ist recht einfach, wenn du C beherrscht. Die meisten C Programme sind auch C++ Programme. Allerdings macht man einige Dinge in C++ anders als in C. Man hat mehr Möglichkeiten, a) um besseren Code zu schreiben b) durch nicht Wissen schlechteren Code zu schreiben c) einige komplizierte/mächtige Konstrukte durch einfache Schlüsselwörter zu ersetzen (davon viele Schlüsselwörter um OOP einfacher zu implementieren) d) Mächtigere Funktionen um Code zu erzeugen / zu verändern Schau mal, ob C++11 / C++14 Erwähnung findet. Durch die Erweiterung der Sprache hat sich einiges geändert. Gruß Felix
Schau mal hier: http://www.mindviewinc.com/Books/downloads.html Bruce Eckel's Thinking in .. Serie ist für OO denken lernen nicht schlecht.
Ratgeber schrieb: > Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird > hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen... Es wird eigentlich nur verlangt, da auch reinzuschauen, wenn man eine Frage hat, statt reflexartig hier zu posten und zu erwarten, daß andere für einen die Stelle im Datenblatt raussuchen. Moby AVR schrieb im Beitrag #3995305: > Klaus Wachtler schrieb: >> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen. > > Das allein würde mir schon arg zu denken geben ob diese Denkweise der > Weisheit letzter Schluß ist. Das Werkzeug sollte sich dem Menschen > anpassen, nicht umgekehrt. Es ist genau anderes herum, als das, was du daraus schließt. OOP beschreibt die Sache eigentlich in einer für den Menschen viel gewohnteren Art. Deshalb wurde OOP ja überhaupt erst erfunden. Die prozedurale Programmierung ist eher die an den Computer angepasste Denkweise. Das Problem ist deshalb nicht OOP an sich, sondern der Wechsel von prozeduraler Programmierung zu OOP. Wenn du die Programmierung gleich mit OOP lernst, wirkt das alles ganz natürlich. Wenn du aber schon prozedurale Programmierung gewöhnt bist, mußt du dich erst wieder komplett umgewöhnen. Dr. Sommer schrieb: > Warum immer alle Angst vor OOP haben verstehe ich nicht. Auch viele C- > Programme verwenden OOP, Einige davon aber nicht so richtig, sondern nutzen ein paar Elemente davon, teils ohne es wirklich zu merken.
Rolf Magnus schrieb: > Es ist genau anderes herum, als das, was du daraus schließt. OOP > beschreibt die Sache eigentlich in einer für den Menschen viel > gewohnteren Art. Naja, es kommt schon auch auf die Art des Problems an. LED-Blinken ist OO auch nicht einfacher als prozedural, im Gegenteil. Das sieht man ja schon daran, daß Java sinnloserweise eine Klasse mit einer public static void main-Methode braucht; das ist ja eine Vergewaltigung von OOP für etwas, was von der Natur her nicht OO ist: "fang hier an...". Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist nicht Mobys Welt.
Bernd K. schrieb: >> Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird >> hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen... > > Das ist nicht wahr. Niemand hat das je verlangt. Noch nichtmal hier. Schmeiss mal Google an und suche nach der Bedeutung von: ;-) Humorloser Unhold du!!! Und falls du's immer noch nicht geschnallt hast, der Autor dieser Zeilen hat GESCHERZT.
Student schrieb: > Bevor ich nich > dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie > schwierig ihr es einshätzt C++ noch dazuzulernen. Wie schon geschrieben: OOP-Programmieren lernen lohnt sich auf jeden Fall! Auf einem PC oder für Android z.B. auch mit C# oder Java. Aus den "Fehlern" die C++ gemacht hat, haben diese neueren Sprachen gelernt, daher ist hier vieles einfacher, für µC jedoch weniger geeignet. Warum? Falls es um C++ auf einem µC geht, siehe: http://scottmeyers.blogspot.de/2013/02/schulungsunterlagen-zur-anwendung-von-c.html Das wäre dann die Pflichtlektüre vom Guru^^. Ich habe 2 Tage gebraucht, um alles zu verstehen. Aber ich denke, bei Dir wird es um Programmierung auf einem PC (Linux/Windows/...) gehen, oder?
:
Bearbeitet durch User
Klaus Wachtler schrieb: > Rolf Magnus schrieb: >> Es ist genau anderes herum, als das, was du daraus schließt. OOP >> beschreibt die Sache eigentlich in einer für den Menschen viel >> gewohnteren Art. > > Naja, es kommt schon auch auf die Art des Problems an. > LED-Blinken ist OO auch nicht einfacher als prozedural, im Gegenteil. Ja, wer nicht über die blinkende LED hinaus blicken kann, kann mit OOP natürlich nichts anfangen. > Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist > nicht Mobys Welt. Allerdings. Es kommt aber auch darauf an, wie stark man abstrahiert. Es ist auch möglich, "zuviel OOP" zu machen und sich in nachher niemals notwenigen Klassenhierarchien zu verkünsteln. Aber jedes Programmierwerkzeug kann missbraucht werden. Wie hieß es so schön? You can write FORTRAN in any language. > Das sieht man ja schon daran, daß Java sinnloserweise eine Klasse mit > einer public static void main-Methode braucht; das ist ja eine > Vergewaltigung von OOP für etwas, was von der Natur her nicht OO ist: > "fang hier an...". Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es Java tut. Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale Programmierung in den OOP-Schuh gezwängt. Eine Klasse, die nicht instanziiert werden soll und von der auch nicht abgeleitet werden soll, ist für mich irgendwie widersinnig.
:
Bearbeitet durch User
Rolf Magnus schrieb: > Eine Klasse, die nicht > instanziiert werden soll und von der auch nicht abgeleitet werden soll, > ist für mich irgendwie widersinnig. Tja, wenn man keine namespaces hat :-)
Rolf Magnus schrieb: > Eine Klasse, die nicht > instanziiert werden soll und von der auch nicht abgeleitet werden soll, > ist für mich irgendwie widersinnig. Naah, die sind schon sinnvoll. Wenn eine klasse ausschließlich mit statischen Methoden auskommt, muss sie weder instanziierbar noch ableitbar sein...
Rolf Magnus schrieb: > Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es > Java tut. Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die > ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale > Programmierung in den OOP-Schuh gezwängt. Eine Klasse, die nicht > instanziiert werden soll und von der auch nicht abgeleitet werden soll, > ist für mich irgendwie widersinnig. Von den meisten Klassen sollte nicht geerbt werden, OOP ist nicht dazu da ueberall und alles zu vererben, vor allem nicht nur um Code wiederzuverwenden. Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der OOP ist immer noch "Daten und Operationen auf diese Daten sollten zusammensein". Vererbung bietet sich an, wenn man gemeinsame Schnnittstellen hat und ausdruecken will "Ist ein", Vererbung hat aber eben den Nachteil der starken Kopplung, Vererbung zu nutzen nur um Code wiederzuverwenden gilt als Missbrauch. Stimme dir zu was die Helper Klassen betrifft, statische Methoden machen das Mocken schwieriger und zB. in Java schliessen sich static Methoden und Schnittstellenvererbung aus, fuehrt dann zum sog. "shadowing".
:
Bearbeitet durch User
Ich finde sogar, auch LED-Blinker gehen in OOP:
1 | int main () { |
2 | pinB13.initialize (OUTPUT); |
3 | while (true) { |
4 | pinB13.set (1); |
5 | delay (1000); |
6 | pinB13.set (0); |
7 | delay (1000); |
8 | }
|
9 | }
|
Geeignetes API vorrausgesetzt natürlich. Ist dieser Code unnötig komplex und lang gegenüber prozeduraler Programmierung? Finde ich nicht. Hardware-Einheiten wie Pins, USARTS, Timer etc. sind doch in der Realität Objekte, warum nicht auch in der Programmiersprache als Objekte darstellen? Rolf Magnus schrieb: > Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es > Java tut. Keine Sprache kann OOP erzwingen. Wenn in in Java alles in eine Klasse schreibe ist das kein OOP (auch wenn da 1x "class" im Code vorkommt). Dass Java keine globalen Funktionen&Variablen kann vereinfacht die Sprache, und Java ist auf Einfachheit ausgelegt. Und mal ehrlich, so schlimm ist es nicht, einmal "class Blubb {" vor die main() zu schreiben...
Student schrieb: > Ich programmiere schon seit ein paar Jahren C und wrüde sagen, dass ich > auch ganz gut darin bin. Dieses Semeser habe ich eine C-Lehrveransatung > mit der Höchstunktezahl abgeschlossen Nach meiner Erfahrung bedeutet das leider nichts. Der Unterricht ist meistens eher von schlechter Qualität, ob an den Berufsschulen oder an den Hochschulen. Wenn man Glück hat, hat man einen Dozenten der sich wirklich auskennt und den Stoff zu vermitteln weiß. Aber das scheint eher eine Ausnahme zu sein als die Regel (vor allem bei C++). Unser Professor war ein Microsoftjünger, benutze fflush(stdin) und zwang uns die ungarische Notation zu benutzen (nach seiner Meinung total verbreitet. Nur lustig dass Microsoft keine ungarische Notation mehr benutzt seit der WinAPI ;) ). Achso i++ war natürlich auch noch schneller als i+=1. Kaum zu glauben, dass er mal in der Wirtschaft tätig war. Klaus Wachtler schrieb: > Die schlechte Nachricht: > alles zu C++ lernen = keine Chance, das dauert ewig Was zum Glück auch nicht sinnvoll ist. OOP ist wirklich genial und kommt unseren Denken auch sehr viel näher als reine prozedurale Programmierung. Man sollte allerdings nicht alles in ein Objekt quetschen nur weil es geht, den Fehler sieht man leider oft. Java und C# erzwingen das ja quasi (geht sonst nur über statische Methoden).
TriHexagon schrieb: > Achso i++ war natürlich auch noch > schneller als i+=1. Kaum zu glauben, dass er mal in der Wirtschaft tätig > war. Als Kellner. Da muß man schnell addieren können. ;-) MfG Paul
Boris P. schrieb: > Rolf Magnus schrieb: >> Eine Klasse, die nicht instanziiert werden soll und von der auch nicht >> abgeleitet werden soll, ist für mich irgendwie widersinnig. > > Naah, die sind schon sinnvoll. Wenn eine klasse ausschließlich mit > statischen Methoden auskommt, muss sie weder instanziierbar noch > ableitbar sein... Hast du den Teil davor auch gelesen? Hier ist er nochmal: Rolf Magnus schrieb: > Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die > ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale > Programmierung in den OOP-Schuh gezwängt. Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung, weil Java halt keine freistehenden Funktionen unterstützt, man sie aber eigentlich manchmal doch bräuchte. Mladen G. schrieb: >> Eine Klasse, die nicht instanziiert werden soll und von der auch nicht >> abgeleitet werden soll, ist für mich irgendwie widersinnig. > > Von den meisten Klassen sollte nicht geerbt werden, OOP ist nicht dazu > da ueberall und alles zu vererben, vor allem nicht nur um Code > wiederzuverwenden. Das hab ich ja auch nicht behauptet. Aber wenn die Klasse weder instanziiert, noch von ihr geerbt wird, bleibt gar nichts objektorientiertes mehr übrig. Ich habe also einen grundlegenden Bestandteil der OOP - die Klasse - verwendet, um damit etwas umzusetzen, das mit OOP nichts mehr zu tun hat. Und das ist wie gesagt in meinen Augen widersinnig. > Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der > OOP ist immer noch "Daten und Operationen auf diese Daten sollten > zusammensein". Das habe ich ja selbst auch schon geschrieben: Rolf Magnus schrieb: > Es ist auch möglich, "zuviel OOP" zu machen und sich in nachher niemals > notwenigen Klassenhierarchien zu verkünsteln.
Rolf Magnus schrieb: > Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung, > weil Java halt keine freistehenden Funktionen unterstützt Doch, so werden die Methoden sauber gruppiert und sind alle in einem "Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich übersichtlicher, als einzelne Funktionen lose im Quellcode herumschwimmen zu haben... Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach als statische Member der Klasse untergebracht werden können. Bei freischwebenden Funktionen müsste man daraus dann globale Variablen (ugh!) machen...
Boris P. schrieb: > Rolf Magnus schrieb: >> Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung, >> weil Java halt keine freistehenden Funktionen unterstützt > > Doch, so werden die Methoden sauber gruppiert und sind alle in einem > "Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich > übersichtlicher, als einzelne Funktionen lose im Quellcode > herumschwimmen zu haben... > > Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach > als statische Member der Klasse untergebracht werden können. Bei > freischwebenden Funktionen müsste man daraus dann globale Variablen > (ugh!) machen... Danke dafür, dass Du meine Antwort geschrieben hast. Genau so sollte sie aussehen ;-) Ein Namespace ist schon ganz angenehm, eben weil da die Variablen nicht einfach auf der globalen Ebene "rumfliegen". Grundsätzlich ist OOP wohl intuitiver, allerdings nicht für Leute, die durch prozedurale Programmierung schon "verdorben" sind. Ich habe mich damals auch erst schwer getan, das Konzept zu verstehen. Aber danach ist es eigentlich die logische Abbildung von realen Problemen.
Student schrieb: > Bevor ich mich > dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie > schwierig ihr es einschätzt C++ noch dazuzulernen. Schwierig nicht, aber man steht plötzlich vor vielen Fragen der SW-Architektur, die man ohne OOP nie gestellt hätte. Das zeigt auch die Diskussion, die hier gerade (wieder!) entbrennt. Nun lasst doch erstmal 'Student (Gast)' zu Wort kommen! 'Diskussionen zum Sebstzweck' haben wir im Beitrag "C++ auf einem MC, wie geht das?" Klaus Wachtler schrieb: > Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist > nicht Mobys Welt. Ach, geht das hier jetzt auch los? ;-) Der arme 'Student (Gast)' wird viel Stoff zum Lesen bekommen!
:
Bearbeitet durch User
Boris P. schrieb: > Doch, so werden die Methoden sauber gruppiert und sind alle in einem > "Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich > übersichtlicher, als einzelne Funktionen lose im Quellcode > herumschwimmen zu haben... > > Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach > als statische Member der Klasse untergebracht werden können. Bei > freischwebenden Funktionen müsste man daraus dann globale Variablen > (ugh!) machen... Chris D. schrieb: > Danke dafür, dass Du meine Antwort geschrieben hast. Genau so sollte sie > aussehen ;-) Ich habe auch erst anfangen wollen, einen änlichen Text zu schreiben, aber bei genauerem Überlegen dann auch festgestellt, dass er recht hat. Die Funktionen/Member würden sich ja ohnehin im Namensraum des Packages befinden (im weitesten Sinne das, was bei c++ die Namespaces sind). Sie würden also keineswegs wie bei C den globalen Namensraum verschmutzen. Edit: Bei C++ ist eine Klasse mit nur statischen Methoden ja quasi äquivalent zum einem Namensraum, hat aber den Nachteil, dass man nix "von außen" hinzufügen kann.
:
Bearbeitet durch User
Boris P. schrieb: > Rolf Magnus schrieb: >> Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung, >> weil Java halt keine freistehenden Funktionen unterstützt > > Doch, so werden die Methoden sauber gruppiert und sind alle in einem > "Namensraum" (= Name der Klasse) zu finden. Dazu gibt es (zumindset in C++) Namespaces. Man muss dafür nicht extra eine ansonsten nutzlose Klasse anlegen. > Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach > als statische Member der Klasse untergebracht werden können. Bei > freischwebenden Funktionen müsste man daraus dann globale Variablen > (ugh!) machen... Wo ist denn deiner Meinung nach der große Unterschied zu einer globalen Variable? Ich hab schon häufig gesehen, daß irgendwelche merkwürdigen Verrenkungen gemacht werden, um globale Variablen durch was zu ersetzen, das auch nicht besser ist, aber offiziell dann nicht mehr als globale Variable gilt. So wie z.B. der Mißbrauch von Singletons, der in dem Zusammenhang auch oft begangen wird.
Mladen G. schrieb: > Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der > OOP ist immer noch "Daten und Operationen auf diese Daten sollten > zusammensein". Nein. Da war nie "das Konzept" von OOP. Eine verbreitete Strömung der OOP-Sprachen hat diesen (einschränkenden) Weg gewählt. Andere OOP-Sprachen trennen Daten und Methoden strikt. Ein Beispiel wäre Common Lisp. Gibt noch andere.
Rolf Magnus schrieb: > Wo ist denn deiner Meinung nach der große Unterschied zu einer globalen > Variable? Dass die Variable nur innerhalb der Klasse sichtbar ist. Somit kann ich sicher sein, dass diese nicht von anderen Stellen aus verwendet werden kann.
Boris P. schrieb: > Dass die Variable nur innerhalb der Klasse sichtbar ist. Somit kann ich > sicher sein, dass diese nicht von anderen Stellen aus verwendet werden > kann. wenn ich das nicht will, kann ich sie genauso gut statisch im c/cpp file definieren und muss sie nicht im Header als extern exportieren.
Marc schrieb: > Mladen G. schrieb: >> Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der >> OOP ist immer noch "Daten und Operationen auf diese Daten sollten >> zusammensein". > > Nein. Da war nie "das Konzept" von OOP. > > Eine verbreitete Strömung der OOP-Sprachen hat diesen (einschränkenden) > Weg gewählt. > > Andere OOP-Sprachen trennen Daten und Methoden strikt. Ein Beispiel wäre > Common Lisp. Gibt noch andere. Falsch. (um mal auf demselben Niveau zu antworten..) Common Lisp hat auch Elemente von funktionalen Programmiersprachen, und dazu gehoert u.a. die Trennung von Daten und Funktionen. OOP basiert darauf Daten und die Operationen die auf diesen Daten arbeiten in Objekte zu kapseln, sollte man eigentlich im OOP Grundlagenkurs gelernt haben. Vererbung, wenn richtig eingesetzt (http://en.wikipedia.org/wiki/Liskov_substitution_principle), kommt viel seltener zum Einsatz als viele glauben.
Rolf Magnus schrieb: > OOP > beschreibt die Sache eigentlich in einer für den Menschen viel > gewohnteren Art. Denkt man erst einmal. Stimmt leider nicht. Ist ein Kreis etwa keine Ellipse? http://en.wikipedia.org/wiki/Circle-ellipse_problem
Mladen G. schrieb: > Falsch. (um mal auf demselben Niveau zu antworten..) Informier dich doch erstmal. > Common Lisp hat auch Elemente von funktionalen Programmiersprachen, und > dazu gehoert u.a. die Trennung von Daten und Funktionen. Das Common Lisp Object System (CLOS) ist Objektorientierung. Im übrigen könntest du dich auch mal über generic functions oder auch multiple dispatch schlaumachen. Die Verquickung von Daten und Methoden führt nämlich direkt zu single dispatch, nämlich einem ausgezeichneten, "führenden" Objekt beim Dispatch: üblicherweise this genannt. Und daher kommen dann auch Verrenkungen wie friend in C++.
Vlad Tepesch schrieb: > wenn ich das nicht will, kann ich sie genauso gut statisch im c/cpp file > definieren und muss sie nicht im Header als extern exportieren. Joar, kann man so machen. Wenn man's mag ;-)
Dr. Sommer schrieb: > Klaus Wachtler schrieb: >> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen > Als ob, das ist noch schön einfach und leicht vorstellbar. Warum immer > alle Angst vor OOP haben verstehe ich nicht. Man kann schon ganz schön lange über Probleme nachdenken, die man ohne OOP gar nicht gehabt hätte. Allein schon das Beispiel 'Ist ein Kreis etwa keine Ellipse'^^ zeigt, vor welchen Entscheidungen man hier steht. Und bei C++11 wird´s noch schlimmer! > * Fehlschlagspezifikation für die Größenanpassung > * Vertauschen der Vererbungsrichtung > * Verzicht auf eine Spezialisierung > * Verzicht auf eine Vererbungsbeziehung > * Erweiterung der Vererbungshierarchie > * ... Bücher wurden ja schon empfohlen. Man sollte sich verschiedene Typische Patterns anschauen ("Entwurfsmuster" unter Wikipedia), bevor man mit der Einstellung "das ist … einfach und leicht vorstellbar"^^ anfängt und merkt, dass man auf dem Holzweg war, wenn man eigentlich mit der SW schon fertig sein wollte. Wer kennt das? Wem ist das noch nie passiert? BTW: Nachdem wir im anderen Thread bereits Peter Dannegger 'verloren' haben, hängen wir hier auch gerade den OP 'Student (Gast)' ab. Oder? @Student: Sag doch mal was! Konnten wir Dir helfen? Hast Du Dich schon entschieden?
:
Bearbeitet durch User
Torsten C. schrieb: > Man kann schon ganz schön lange über Probleme nachdenken, die man ohne > OOP gar nicht gehabt hätte. die gleichen Probleme stellen sich bei klassischer imperativer programmierung aber genauso. MAn hat ein Haufen komplexer Anforderungen, die nicht trivial zu lösen sind und muss irgendwie einkomplexes System Programmieren, dessen EInzelteile dennoch ÜBerschaubar sind und das am besten noch mit einer Feinen Gui gesteuert werden kann. Hier hat sich der objektorientierte Ansatz nunmal am besten bewährt. Während darüer diskutiert wird, welche Entwurfsmuster zur Abbildung am besten geeignet sind, stellt sich die Frage in C meistens nicht, weil man hier immer noch damit beschäftigt ist die Basisfunktionalität, die C++ schon mitbringt zusammenzuschustern und froh ist, wenn die erst msl läuft und dann den den Rest aufgrund von Zeitmangel irgendwie reinfummelt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.