Performancemythen?

Xin

Mr. N schrieb:

Xin schrieb:

...

Das stimmt soweit natürlich alles.

Cool. :->

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Ich weiß nicht, was Du hier konkret als Unfug bezeichnest, entsprechend kann ich Dir auch nichts erläutern oder Dir sagen, wie ich darauf komme, es hier zu schreiben.

Zwei Dinge kann ich jedoch beantworten. Erstens: Ich schreibe keinen Unfug und zweitens: ich schreibe hier nicht, um Erwartungen zu entsprechen.

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird. Wenn das nicht bekannt ist, so sollten wenigstens die sich daraus ergebenen Vor- und Nachteile sollten bekannt sein. Die habe ich in dem Bereich aufgeführt, den Du als Unfug bezeichnest.

Cpt. Nukem schrieb:

Ich versteh zwar den Zusammenhang nicht, dass etwas langsamer ist, weil es eine Technik ist.

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

Das macht man, um Entscheidungen nicht treffen zu müssen.
Die Umsetzung von OOP in C++ ist also auch eine Technik, die hilft bei komplizierten Fragestellungen den Überblick zu behalten und notwendige Fragen in grundsätzlich nur 3 Schritten zu beantworten. Das hilft Zeit zu sparen, denn ein Algorithmus, der fragt, bräuchte mehr Schritte.

Nutzt man OOP bei Funktionsrufen, wo keine Entscheidungen zu treffen sind, so verliert man Zeit. Nutzt man OOP bei Funktionen, die objektabhängig sind, spart man Zeit oder viel Aufwand und erhält übersichtlichen Code. Man verliert in dem Fall aber keine Zeit, weil die Entscheidung muss so oder so getroffen werden. Und in der Regel wird sie schlechter implementiert, als es C++ macht. In dem Fall ist OOP mit C++ schneller.
Man muss OOP sinnvoll und bewußt einsetzen.

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Richtig. Hier verliert man bei ungeschickter Programmierung (z.B. i++ statt ++i) unnötig Zeit.

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Macht man sich vom Objekttyp abhängig, programmiert das Ganze also objektorientiert statt sich auf die aktuelle Sichtweise auf das Objekt zu konzentrieren (klassenorientiert), dann wird der Funktionsaufruf dynamisch und zur Laufzeit ermittelt.

Cpt. Nukem schrieb:

Man kann natürlich noch weiter gehen und sagen, dass Funktionsaufrufe Zeit brauchen, darum sollte man alles direkt hinschreiben. Macht wohl keiner.

Würde auch keinen Sinn machen, da nicht ohne Funktionsaufrufe kaum etwas programmieren kann. Um z.B. Bäume zu durchwandern, müsste man sich in dem Fall den Stack selbstbauen, weil man rekursive Algorithmen nicht direkt hinschreiben kann. Man spart in dem Fall also auch nichts.

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.
Das ist aber sehr programmabhängig, die Zahlen sind also bestenfalls wage Anhaltspunkte, ich habe sie aber schon in verschiedenen Büchern zu dem Thema gesehen. Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird. Doch auch die C++ Compiler werden immer besser. Die Qualität der C++-Übersetzungen wird sich mehr und mehr an C annähern, genauso wie sich C an Assembler weiter annähern wird. Trotzdem kann man davon ausgehen, dass C++-Programme langsamer bleiben als C-Programme, weil irgendeine Ungeschicktheit findet sich vermutlich in jedem C++-Programm.

Die Zahlen sind alt, die Differenz sollte inzwischen kleiner sein, aber selbst würde ein Programm 10x langsamer laufen, hilft C++ deutlich, Programme übersichtlicher und damit fehlerfreier zu gestalten. Ein Programm, dass nach 10 Stunden zum Ziel kommt ist effizienter als ein Programm, das nach 1 Stunde ein falsches Ergebnis liefert.

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

(Oder) gilt es heute wirklich schon als Diskussionsargument, wenn man die Aussage des Vorredners wiederholt und behauptet, man würde ihm so widersprechen?

Lies doch nochmal nach, wogegen Du widersprichst:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Mr. N

Xin schrieb:

Mr. N schrieb:

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Ich weiß nicht, was Du hier konkret als Unfug bezeichnest, entsprechend kann ich Dir auch nichts erläutern oder Dir sagen, wie ich darauf komme, es hier zu schreiben.

So wie das da stand war das verallgemeinernder Quark.

Xin schrieb:

Zwei Dinge kann ich jedoch beantworten. Erstens: Ich schreibe keinen Unfug und zweitens: ich schreibe hier nicht, um Erwartungen zu entsprechen.

Nicht gleich beleidigt sein. :p

Xin schrieb:

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird.

Ich kenne den Begriff OOP schon eine Weile. Und ich weiß, dass er vor allem schwammig ist. Ich weiß aber auch, dass OOP nicht äquivalent zu virtuelle Klassenmethoden ist (ich vermute, das meinst du mit "OOP", aber sicher bin ich auch nicht).

Xin schrieb:

Wenn das nicht bekannt ist, so sollten wenigstens die sich daraus ergebenen Vor- und Nachteile sollten bekannt sein. Die habe ich in dem Bereich aufgeführt, den Du als Unfug bezeichnest.

Bevor ich das weiter kommentiere warte ich lieber auf deine Definition von OOP.

Xin schrieb:

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

In gewissen Fällen muss der Compiler die virtuelle Methode nicht indirekt aufrufen.

Xin schrieb:

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Besteht für dich alles nur aus Implementierungsphilosophie? Doch, wenn ich eine Zahlen-Klasse habe, würde ich das meistens OOP nennen. (Wobei in C++ die Grenzen verwischen.)

Xin schrieb:

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.

Woher hast du den Unfug? Wird ja immer krasser. Mir ist diese Annahme neu und sie wird auch meistens falsch sein. (GNOME ist nicht 5-mal schneller als KDE, vergleichbar sind beide aber sehr wohl.)

[Allerdings benutze ich selbstverständlich aktuelle Compiler, für mich ist die Zeit nicht vor 10 Jahren stehen geblieben.]

Xin schrieb:

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

Ich denke nicht, dass tntnet im Marketing-Bereich arbeitet.

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Das ist inkonsistent. Sind Arrays nun schneller oder nicht?

hustbaer

Ist ja krass wie ihr euch hier gegenseitig beflegelt, und das ganz ohne "Java vs. C++" Flamewar. Da soll nochml wer sagen Programmierer seien unflexibel.

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Ich für meinen Teil denke dass es gewisse "Techniken" gibt die man "OOP" zuordnen kann. Einige gehen auf Kosten der Performance, andere nicht oder kaum.

Mr. N

hustbaer schrieb:

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Klar.

OOP: Schwammiger Begriff, in C++ meist: alles was nach Objekt riecht, allerdings auch eine Anzahl von Design-Richtlinien, im Zweifelsfalle eher weit zu interpretieren.

Hustbaer schrieb:

Ich für meinen Teil denke dass es gewisse "Techniken" gibt die man "OOP" zuordnen kann. Einige gehen auf Kosten der Performance, andere nicht oder kaum.

Stimme zu.

Xin

Hallo Mr. N

Bevor Du antwortest, lies es erstmal komplett.

Mr. N schrieb:

Xin schrieb:

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird.

Ich kenne den Begriff OOP schon eine Weile. Und ich weiß, dass er vor allem schwammig ist. Ich weiß aber auch, dass OOP nicht äquivalent zu virtuelle Klassenmethoden ist (ich vermute, das meinst du mit "OOP", aber sicher bin ich auch nicht).

Deine Vermutung ist korrekt. Was nicht korrekt ist ist, dass Du weißt, dass OOP ein schwammiger Begriff ist.
Der Begriff OOP läßt sich sehr exakt formulieren, man muss es nur tun.
Und für die meisten ist er schwamming, weil die meisten glauben, dass objektorientiert = C++ - C ist.
Wenn einem das nicht griffig genug ist, besteht die Möglichkeit mal darüber nachzudenken. Es würde auch vollkommen reichen OOP mal auszuschreiben und sich Gedanken darüber zu machen, was die einzelnen Worte, die OOP abkürzt, überhaupt bedeuten und warum man genau diese Worte gewählt hat, um eine Technik zu bezeichnen.

Klassenbasiert ist alles, was mit Datenstrukturen zu tun haben, die ausschließlich auf den aktuell verwendeten Datentyp - eben die Klasse - fixiert sind und Daten eben klassifizieren. Du könntest Dir in dem Zusammenhang kurz Gedanken machen, warum das Schlüsselwort in allen gängigen Sprachen "class" heißt und nicht "object".
Katzen gehören zur Klasse der Tiere, welche zur Klasse der Lebewesen gehören. Bis hierhin gibt es noch nichtmal ein Objekt, keine existierende Katze, kein existirendes Tier, lediglich die Feststellung, dass derartige Objekte - sollten sie irgendwann existieren - irgendwie klassifiziert werden und dass zwischen Katzen und Tieren eine gerichtete Verbindung besteht.
Beim Zugriff auf die Objekte orientiert sich die Sprache an der Klasse, die man zur Zeit betrachtet. Ein Tier ist eine andere Klasse als eine Katze und Tiere machen alles wie Tiere und Katzen machen alles wie Katzen. Katzen sind Tiere und eine Objekt, das als Tier aufgefordert wird etwas zu tun, interessiert sich nicht die Bohne, dass Katzen das lieber anders machen würden.
Alles statisch, eben nicht objektorientiert, aber eben mit 'class'es klassifiziert.

Objektorientiert wird das ganze in dem Moment, wo es eben nicht mehr um die Klasse, sondern um die Klasseninstanz - das Objekt - geht. Eine Katze ist eine Instanz der Klasse Tier und genauso eine Instanz der Klasse Lebewesen. Da jedoch nicht mehr alleine auf die Klassifizierung Wert gelegt wird, sondern man sich am wirklichen Typ der Datenstruktur - des Objektes - orientiert, verhält sich ein Objekt Katze der Klasse Tier wie eine Katze, genauso wie ein Objekt Katze der Klasse Lebewesen sich wie eine Katze verhält.
Man arbeitet objektorientiert und damit sich das von klassenorientierter Programmierung unterscheidet, nehme man in C++ das Schlüsselwort "virtual".

Um etwas zu klassifizieren kann man in C++ "class" nehmen. Es geht in C aber genauso gut mit "struct".
Nur weil man der Sprache mitteilen kann, dass Funktionen einer Datenstruktur zugehörig ist, wird daraus kein OOP.
Eine "class" ist eine Struktur mit einem eigenen Namensraum und beim Aufruf von Methoden steht das erste Argument links vom Methodennamen. Mehr ist das nicht und solange da kein virtual drin steht, ist es problemlos und ohne Aufwand in C abzubilden, weil man keine OOP Unterstützung benötigt.

Mr. N schrieb:

Xin schrieb:

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

In gewissen Fällen muss der Compiler die virtuelle Methode nicht indirekt aufrufen.

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Ansonsten bin ich neugierig, was jetzt kommt.

Mr. N schrieb:

Xin schrieb:

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Besteht für dich alles nur aus Implementierungsphilosophie? Doch, wenn ich eine Zahlen-Klasse habe, würde ich das meistens OOP nennen. (Wobei in C++ die Grenzen verwischen.)

Meistens? Mal ja, mal nein? Natürliche Zahlen haben nur ein bißchen OOP, Komplexe sind kompliziert, deswegen müssen die in OOP geschrieben werden?
Wovon hängt das ab? Uhrzeit? Tagesform? Wetter?
In C++ verwischen Grenzen? Ist OOP in C++ was anderes als in Simula, Java, oder warum verwischen Grenzen grade in C++?

Wenn ich eine Klasse habe, würde ich von einer Klasse sprechen. Darum heißen die Dinger Klassen, vermute ich.
Ein Instanz einer Klasse ist ein Objekt - wie auch ein Array, ein Integer und alles, was aus mehr als void besteht.
Wenn sich das Programm am Datentyp der Klasse orientiert, nenne ich das klassenorientiert.
Wenn sich das Programm am Datentyp des Objektes orientiert, nenne ich das objektorientiert.

Solange kein virtual in der Klasse auftaucht, besitzt das Objekt keine Typinformation und reagiert unabhängig vom Typ des Objektes auf den Referenztyp der Klasse. Und der Referenztyp der Klasse muss nicht dem Typ des Objektes entsprechen. Es orientiert sich nicht am Typ des Objektes. Wenn sich etwas nicht am Objekt orientiert, wüßte ich nicht, wieso man von objektorientierter Programmierung sprechen sollte.

Ich sehe keine Grenzen, die hier verwischen. Ich sehe hier sehr scharf gezogene Grenzen in den Definitionen.

Die "Implementierungsphilosophie" gibt vor, was wie programmiert wird. OOP kann man in einen Compiler implementieren. Dafür gibt es Algorithmen. "Kompilier mir eine Textverarbeitung besser als OpenOffice" ist ein toller Sourcecode, aber Kreativität ist bisher als Programmiertechnik nicht beschrieben. Hier scheitert Philosophie an der Implementierung.
Für mich ein guter Grund, erst nach der Implementierung zu fragen und dann nach der Philosophie von Nachwuchsentwicklern.

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.

Woher hast du den Unfug? Wird ja immer krasser. Mir ist diese Annahme neu und sie wird auch meistens falsch sein. (GNOME ist nicht 5-mal schneller als KDE, vergleichbar sind beide aber sehr wohl.)

Bist Du in der Lage, drei Sätze weiter zu lesen und zu kapieren, warum ich extra für Dich Worte fett schreibe und unterstreiche?
Ja, es ist eine rhetorische Frage...

Aber um Deine Frage zu beantworten: "Programmierpraxis" von Brian Kernigham und Rob Pike. Dort wurden Laufzeittests in verschiedenen Sprachen gefahren und Programme mit entsprechenden Sprachmerkmalen umgesetzt, was in C++ STL bedeutete.

Mr. N schrieb:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Das ist inkonsistent. Sind Arrays nun schneller oder nicht?

Es ist schon spät, oder? Wenn's für Dich zu spät wird, dann geh besser schlafen. Derartige Äußerungen sind unpraktisch, wenn man anderen unterstellt Unfug zu schreiben.

Ein Ferrari ist schneller als ein Traktor.
Und wenn Du Bauer wirst, kaufst Du Dir einen Ferrari, weil Du damit Deine Felder schneller bestellen kannst. Das ist Deine Auffassung von konsistent? Merkst Du was? Spätestens, wenn der Traktor den Ferrari aus dem Dreck zieht, wirst Du's merken.

(Ich meine die Sportwagen... nur für den Fall, dass Du rausbekommst, dass es auch Ferrari-Traktoren gibt...^^ )

Da das Buch auf dem Schreibtisch liegt, schlage ich für extra Dich nochmal in "Design und Entwicklung von C++" nach, Seite 92, Kapitel "3.5 - Virtuelle Methoden". Wenn Fettdruck nicht reicht, vielleicht hilft Bjarne.

Bjarne Stroustrup schrieb:

Das Problem liegt darin, dass hier nicht zwischen den allgemeinen Eigenschaften einer beliebigen Form [...] und den speziellen Eigenschaften einer bestimmten Form (ein Kreis ist eine Form, die einen Radius besitzt [...]) unterschieden wird. Derartige Unterschiede auszudrücken und zum Vorteil zu verwandeln macht objektorientierte Programmierung aus. Eine Sprache mit Konstrukten, die die Beschreibung und Verwendung derartiger Unterschiede erlauben, unterstützt OOP. Eine Sprache, der diese Eigenschaften fehlen, tut es nicht.

Daraus 2 Schlussfolgerungen:
1. ohne virtual, keine OOP-Unterstützung. Also Klassen ohne virtual: keine OOP Unterstützung, weil sie auch nix mit OOP zu tun haben.
2. Unterstützung bedeutet nicht, dass OOP ohne virtual nicht möglich wäre. Auch in C kann man OOP programmieren, aber C unterstützt den Entwickler dabei nicht.

Es wäre mir eine Freude, wenn ich Deine verwischten Definitionen von OOP etwas graderücken konnte. Falls Rückfragen sind, ist das kein Problem, solange Du sie nicht mit "Das ist Unfug" einleitest. Auf freundlich gestellte Fragen reagiere ich deutlich positiver als auf "Das ist Unfug", wenn "Das ist Unfug" Unfug ist und nichtmals eine brauchbare Begründung zum Widerspruch gereicht wird.

hustbaer schrieb:

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Die Tage haben wir in einem anderen Thread festgestellt, dass die Herkunft bzw. Bedeutung von Wörtern sich nicht in einer Umfrage erklären lässt, sondern eher durch Recherche.

Ansonsten haben wir nämlich genau das, was Mr. N schreibt: schwammige Begriffe, weil jeder ihn nach seiner subjektiven Meinung auslegt.
Davon gibt es mehr als genug in der Informatik, doch OOP gehört eigentlich nicht dazu.

Ist das eigentlich ein Sport in solchen Threads, die Sätze einzeln zu betrachten und möglichst falsch zu verstehen? Nur damit man was hat bei dem man sagen kann "Falsch", wenn einer was schreibt, was nicht mit der Meinung des anderen übereinstimmt.

Erkenner schrieb:

Ist das eigentlich ein Sport in solchen Threads, die Sätze einzeln zu betrachten und möglichst falsch zu verstehen? Nur damit man was hat bei dem man sagen kann "Falsch", wenn einer was schreibt, was nicht mit der Meinung des anderen übereinstimmt.

Kein Sport sondern gelebte deutsche Kultur. Anstatt das man versucht zu verstehen was der Andere sagen will macht es doch viel mehr Spaß um jeden Preis zu beweisen das der Andere falsch liegt. Dabei heiligt der Zweck die Mittel, will sagen im Zweifelsfall reisst man halt die Aussagen aus dem Kontext und verfälscht sie soweit bis sie halt falsch sind. Auch wäre es ja viel zu anstrengend vor allem längere Postings komplett zu lesen.

Mir scheint es manchmal so zu sein das einige ihr Selbstwertgefühl darüber definieren wieviele Fehler sie bei anderen finden können.

Ist wahrscheinlich die Transition des deutschen Stammtisches in die Welt der Online-Foren...

this-*gt*that

skals schrieb:

blablabla

Bei dir scheint es Tradition zu sein, deine klischeehafte Weltanschauung in Foren zu präsentieren.
Dass in Foren wie diesem geflamed wird, liegt an der Anonymität und der Zielgruppe. Mit Sachen wie Nationalität oder sowas hat das nichts zu tun. (offenbar warst du noch nie in ausländischen Foren)

Undertaker

tntnet schrieb:

Hier kommt doch gleich ein Vorteil von C++ gegenüber C zum Tragen. Bei so einem Anwendungsfall überlege ich mir in C 2 mal, ob ich den Aufwand, eine Liste zu programmieren auf mich nehme...

in C nimmt man einfach einen fertigen code für listen. da muss man nicht jedes mal alles neu programmieren

tntnet schrieb:

Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

was bestimmt oft schwieriger ist als in C.

Xin

Erkenner schrieb:

Ist das eigentlich ein Sport in solchen Threads, die Sätze einzeln zu betrachten und möglichst falsch zu verstehen? Nur damit man was hat bei dem man sagen kann "Falsch", wenn einer was schreibt, was nicht mit der Meinung des anderen übereinstimmt.

Das ist ein Entwicklerforum. Computer lassen sich nicht auf Diskussionen und die Interpretation eines Sourcecodes ein. Mit Computern diskutiert man nicht und einigt sich dann auf einen Kompromis.
Man teilt die Meinung des Computers oder lässt es.
Dann kommt man mit dem Computer zurecht oder lässt es.
Binäre Logik. True oder False - und damit sollte ein Programmierer umgehen können und wenn er erkennt, dass er etwas falsch macht, sollte er das mitteilen und schon meckert das Gegenüber auch nicht mehr.

skals schrieb:

Kein Sport sondern gelebte deutsche Kultur.

Stimmt, wir Deutschen haben gerne Recht. Und wenn nicht, dann sagen wir gemeine Sachen und werden zickig. Und seit ich auf Kreta wohnte, schätze ich diesen Part der deutschen Kultur.

In Kreta äußert man sein Mißfallen, indem man das Auto des Diskussionsgegners abfackelt.
Sowas verkürzt Diskussionen ungemein. Das ist auch viel harmonischer, da wird auch keiner zickig. Das ist da halt Kultur.
Wenn Du Dein Auto behalten möchtest, einigst Du Dich auf die Meinung desjenigen, der das Feuerzeug hat. So ging es einer Bekannten von mir.

Den Gegner über den Haufen zu ballern ist im Bereich um die größeren Städte nicht mehr in Mode, aber man sollte sich nicht darauf verlassen.
Ein deutscher Kollege von mir hat einen betrunkenen Autofahrer angehalten, weil dieser ihm auf der Autobahn den Spiegel abgefahren hatte. Er war der Meinung, dass ihm Geld für die Reparatur zustünde. Die Polizei kommt nur, wenn's Verletzte gibt und ansonsten ist derjenige Schuld, dessen Auto versichert ist. Deutsche Autos sind versichert, mit Polizei wäre mein Kollege schuld, wenn ihn ein anderer reinfährt.
Das ist wiederum einem anderen Kollegen passiert.
Geld hat besagter Kollege nicht bekommen. Und als er dann zickig zur Arbeit kam, wiesen ihn befreudete Griechen darauf hin, dass dies in Kreta eine gute Situation sei, um sich der alten Traditionen zu erinnern und er besser keine Autos anhält, "nur" weil die mit ihm kollidiert sind. Da bleibt man auf Kreta locker, solange es noch fährt, wird da wird nicht groß rumlammentiert und diskutiert. Ein Spiegel ist eine "Diskussion" nicht wert. Auf Kreta braucht man die sowieso nicht, da braucht man also auch zickig wegen zu werden.
Ich wohnte ein wenig - nicht viel - abseits von Heraklion und dort wird auch gerne mit Verkehrsschildern diskutiert.

Ich kann mit gelebter deutscher Kultur inzwischen recht gut (über-)leben.

Mr. N

Fangen wir erstmal an mit drei Links um die übliche Definition von Objekt-Orientierung zu klären:

Des weiteren glaube ich nicht, dass man praktikabel sagen kann, dass alle diese Aspekte zur Objektorientierung nötig sind, allein schon weil C++ nur einen Teil davon beherrscht.

Xin schrieb:

Hallo Mr. N

Bevor Du antwortest, lies es erstmal komplett.

Hoho, habe ich. Und damit niemand rumzickt kommentiere ich jetzt auch ganze Absätze. (Nein, das brauchst du nicht kommentieren.)

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird.

Ich kenne den Begriff OOP schon eine Weile. Und ich weiß, dass er vor allem schwammig ist. Ich weiß aber auch, dass OOP nicht äquivalent zu virtuelle Klassenmethoden ist (ich vermute, das meinst du mit "OOP", aber sicher bin ich auch nicht).

Deine Vermutung ist korrekt. Was nicht korrekt ist ist, dass Du weißt, dass OOP ein schwammiger Begriff ist.
Der Begriff OOP läßt sich sehr exakt formulieren, man muss es nur tun.
Und für die meisten ist er schwamming, weil die meisten glauben, dass objektorientiert = C++ - C ist.

Der Grund, dass ich ihn für schwammig halte, ist nicht, dass ich nur OOP=C++-C setze.

Schau dir doch bitte mal das hier an: http://paulgraham.com/reesoo.html. (Das ist IMHO der schönste Link zu dem Thema, hat aber nichts mit C++ zu tun.)

Xin schrieb:

Wenn einem das nicht griffig genug ist, besteht die Möglichkeit mal darüber nachzudenken. Es würde auch vollkommen reichen OOP mal auszuschreiben und sich Gedanken darüber zu machen, was die einzelnen Worte, die OOP abkürzt, überhaupt bedeuten und warum man genau diese Worte gewählt hat, um eine Technik zu bezeichnen.

Zum Glück habe ich noch nie in meinem Leben nachgedacht, wie?

Xin schrieb:

Klassenbasiert ist alles, was mit Datenstrukturen zu tun haben, die ausschließlich auf den aktuell verwendeten Datentyp - eben die Klasse - fixiert sind und Daten eben klassifizieren. Du könntest Dir in dem Zusammenhang kurz Gedanken machen, warum das Schlüsselwort in allen gängigen Sprachen "class" heißt und nicht "object".

Weil die Instanz das Objekt ist.

Xin schrieb:

Katzen gehören zur Klasse der Tiere, welche zur Klasse der Lebewesen gehören. Bis hierhin gibt es noch nichtmal ein Objekt, keine existierende Katze, kein existirendes Tier, lediglich die Feststellung, dass derartige Objekte - sollten sie irgendwann existieren - irgendwie klassifiziert werden und dass zwischen Katzen und Tieren eine gerichtete Verbindung besteht.
Beim Zugriff auf die Objekte orientiert sich die Sprache an der Klasse, die man zur Zeit betrachtet. Ein Tier ist eine andere Klasse als eine Katze und Tiere machen alles wie Tiere und Katzen machen alles wie Katzen. Katzen sind Tiere und eine Objekt, das als Tier aufgefordert wird etwas zu tun, interessiert sich nicht die Bohne, dass Katzen das lieber anders machen würden.
Alles statisch, eben nicht objektorientiert, aber eben mit 'class'es klassifiziert.

Objektorientiert wird das ganze in dem Moment, wo es eben nicht mehr um die Klasse, sondern um die Klasseninstanz - das Objekt - geht. Eine Katze ist eine Instanz der Klasse Tier und genauso eine Instanz der Klasse Lebewesen. Da jedoch nicht mehr alleine auf die Klassifizierung Wert gelegt wird, sondern man sich am wirklichen Typ der Datenstruktur - des Objektes - orientiert, verhält sich ein Objekt Katze der Klasse Tier wie eine Katze, genauso wie ein Objekt Katze der Klasse Lebewesen sich wie eine Katze verhält.
Man arbeitet objektorientiert und damit sich das von klassenorientierter Programmierung unterscheidet, nehme man in C++ das Schlüsselwort "virtual".

Ich stimme deiner Definition nicht zu. Encapsulation geht auch ohne Polymorphie und ist doch sehr objektorientiert. Aber da möchte ich dir nochmal den Link von oben ans Herz legen. In diesem Link wird OOP zunächst in mehrere Aspekte aufgeteilt und verglichen, welche der existierenden Varianten von OOP welche Aspekte beherrscht. Meine Konsequenz aus dem Artikel war, OOP möglichst breit zu fassen. Du hingegen definierst OOP als "virtual-Methoden", und das halte ich für gefährlich und falsch.

Xin schrieb:

Um etwas zu klassifizieren kann man in C++ "class" nehmen. Es geht in C aber genauso gut mit "struct".

Es geht auch in C++ mit struct. Der einzige Unterschied ist die Standardsichtbarkeit und gewisse Compilerwarnungen bei delete auf ein unvollständig definiertes class-Objekt (bzw. dessen Pointer).

Xin schrieb:

Nur weil man der Sprache mitteilen kann, dass Funktionen einer Datenstruktur zugehörig ist, wird daraus kein OOP.

Nein, es ist auch noch eine logische Zusammengehörigkeit nötig.

Xin schrieb:

Eine "class" ist eine Struktur mit einem eigenen Namensraum und beim Aufruf von Methoden steht das erste Argument links vom Methodennamen. Mehr ist das nicht und solange da kein virtual drin steht, ist es problemlos und ohne Aufwand in C abzubilden, weil man keine OOP Unterstützung benötigt.

Man kann auch in C, sogar mit structs, objekt-orientiert programmieren, aber wir haben da ja einen definition-mismatch.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

In gewissen Fällen muss der Compiler die virtuelle Methode nicht indirekt aufrufen.

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Ansonsten bin ich neugierig, was jetzt kommt.

Geballte Kompetenz kommt jetzt.

Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Besteht für dich alles nur aus Implementierungsphilosophie? Doch, wenn ich eine Zahlen-Klasse habe, würde ich das meistens OOP nennen. (Wobei in C++ die Grenzen verwischen.)

Meistens? Mal ja, mal nein? Natürliche Zahlen haben nur ein bißchen OOP, Komplexe sind kompliziert, deswegen müssen die in OOP geschrieben werden?
Wovon hängt das ab? Uhrzeit? Tagesform? Wetter?

Der Witz ist, dass meine Zahlenklasse (nennen wir sie rational) sich wie eine Zahl verhält, nach außen hin, die Implementierung aber austauschbar und egal ist.

Xin schrieb:

In C++ verwischen Grenzen? Ist OOP in C++ was anderes als in Simula, Java, oder warum verwischen Grenzen grade in C++?

C++ is a Multi-Paradigm Language.

Xin schrieb:

Wenn ich eine Klasse habe, würde ich von einer Klasse sprechen. Darum heißen die Dinger Klassen, vermute ich.
Ein Instanz einer Klasse ist ein Objekt - wie auch ein Array, ein Integer und alles, was aus mehr als void besteht.

Er benutzt schon selber das wort Objekt. (Ja, ich habe den nächsten Abschnitt gelesen. )

Xin schrieb:

Wenn sich das Programm am Datentyp der Klasse orientiert, nenne ich das klassenorientiert.
Wenn sich das Programm am Datentyp des Objektes orientiert, nenne ich das objektorientiert.

Ich stimme nicht zu.

Xin schrieb:

Solange kein virtual in der Klasse auftaucht, besitzt das Objekt keine Typinformation und reagiert unabhängig vom Typ des Objektes auf den Referenztyp der Klasse. Und der Referenztyp der Klasse muss nicht dem Typ des Objektes entsprechen. Es orientiert sich nicht am Typ des Objektes. Wenn sich etwas nicht am Objekt orientiert, wüßte ich nicht, wieso man von objektorientierter Programmierung sprechen sollte.

Weil OOP mehr als nur ein Aspekt ist.

Xin schrieb:

Ich sehe keine Grenzen, die hier verwischen. Ich sehe hier sehr scharf gezogene Grenzen in den Definitionen.

Wenn ich eine andere Definition habe als du bringt das nix. (Und meine ist von mehreren Links gedeckt, falls dir mein Wort nichts bedeutet.)

Xin schrieb:

Die "Implementierungsphilosophie" gibt vor, was wie programmiert wird. OOP kann man in einen Compiler implementieren. Dafür gibt es Algorithmen. "Kompilier mir eine Textverarbeitung besser als OpenOffice" ist ein toller Sourcecode, aber Kreativität ist bisher als Programmiertechnik nicht beschrieben. Hier scheitert Philosophie an der Implementierung.
Für mich ein guter Grund, erst nach der Implementierung zu fragen und dann nach der Philosophie von Nachwuchsentwicklern.

Man kann dennoch nicht alles an der Implementierung festmachen. (Sehe ich das richtig, dass du behauptest ich sei ein Nachwuchsentwickler? Naja, du scheinst nicht zu wissen, was für Dinge ich mit C++ angestellt habe.)

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.

Woher hast du den Unfug? Wird ja immer krasser. Mir ist diese Annahme neu und sie wird auch meistens falsch sein. (GNOME ist nicht 5-mal schneller als KDE, vergleichbar sind beide aber sehr wohl.)

Bist Du in der Lage, drei Sätze weiter zu lesen und zu kapieren, warum ich extra für Dich Worte fett schreibe und unterstreiche?
Ja, es ist eine rhetorische Frage...

Nein, bin ich nicht. Aussagen sind absolut und diese Aussage ist Unfug. C++ ist nicht 5-10-mal langsamer als C. Vielleicht war das in irgendwelchen prähistorischen Zeiten mal so, aber die sind vorbei.

Xin schrieb:

Aber um Deine Frage zu beantworten: "Programmierpraxis" von Brian Kernigham und Rob Pike. Dort wurden Laufzeittests in verschiedenen Sprachen gefahren und Programme mit entsprechenden Sprachmerkmalen umgesetzt, was in C++ STL bedeutete.

Oho, moderne Vergleiche zeigen aber, dass die Verwendung der STL so gut wie keine Laufzeit kostet. (Aber da das Thema Performancemythen ist, können wir den Faktor 5-10 wunderbar zum Thema zählen.)

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Das ist inkonsistent. Sind Arrays nun schneller oder nicht?

Es ist schon spät, oder? Wenn's für Dich zu spät wird, dann geh besser schlafen. Derartige Äußerungen sind unpraktisch, wenn man anderen unterstellt Unfug zu schreiben.

Nein, ich stehe zu der Aussage.

Xin schrieb:

Ein Ferrari ist schneller als ein Traktor.

Da stimme ich uneingeschränkt zu.

Xin schrieb:

Und wenn Du Bauer wirst, kaufst Du Dir einen Ferrari, weil Du damit Deine Felder schneller bestellen kannst. Das ist Deine Auffassung von konsistent? Merkst Du was? Spätestens, wenn der Traktor den Ferrari aus dem Dreck zieht, wirst Du's merken.

Nun, dein Vergleich hinkt. Bei einem Automobil ist die Geschwindigkeit die Geschwindigkeit auf der Straße. Bei einem Programmierkonstrukt ist die Geschwindigkeit die Geschwindigkeit der Operationen. Vergleichen wir mal ein paar Operationen:

Erzeugen leeres Array versus leere Liste: Array ist teurer (Speicherallozierung kostet ein klein bisschen was).

Traversierung: Liste ist teuerer.

Anhängen ans Ende: Eigentlich geht das mit Arrays nicht, aber wenn wir so tun als ob, ist das Array schneller.

Einfügen sonstwohin: Liste ist schneller.

Woraus ziehst du deine Aussage, Arrays wären schneller?

Xin schrieb:

(Ich meine die Sportwagen... nur für den Fall, dass Du rausbekommst, dass es auch Ferrari-Traktoren gibt...^^ )

Nein, das bekomme ich nicht heraus.

Xin schrieb:

Da das Buch auf dem Schreibtisch liegt, schlage ich für extra Dich nochmal in "Design und Entwicklung von C++" nach, Seite 92, Kapitel "3.5 - Virtuelle Methoden". Wenn Fettdruck nicht reicht, vielleicht hilft Bjarne.

Bjarne Stroustrup schrieb:

Das Problem liegt darin, dass hier nicht zwischen den allgemeinen Eigenschaften einer beliebigen Form [...] und den speziellen Eigenschaften einer bestimmten Form (ein Kreis ist eine Form, die einen Radius besitzt [...]) unterschieden wird. Derartige Unterschiede auszudrücken und zum Vorteil zu verwandeln macht objektorientierte Programmierung aus. Eine Sprache mit Konstrukten, die die Beschreibung und Verwendung derartiger Unterschiede erlauben, unterstützt OOP. Eine Sprache, der diese Eigenschaften fehlen, tut es nicht.

Daraus 2 Schlussfolgerungen:
1. ohne virtual, keine OOP-Unterstützung. Also Klassen ohne virtual: keine OOP Unterstützung, weil sie auch nix mit OOP zu tun haben.
2. Unterstützung bedeutet nicht, dass OOP ohne virtual nicht möglich wäre. Auch in C kann man OOP programmieren, aber C unterstützt den Entwickler dabei nicht.

Bjarne hat den Begriff OOP wohl kaum erfunden. Davon abgesehen mag virtual helfen, OO zu programmieren, aber wenn eine Klasse mal ohne virtual auskommt ist sie deswegen nicht gleich unobjektorientiert.

Xin schrieb:

Es wäre mir eine Freude, wenn ich Deine verwischten Definitionen von OOP etwas graderücken konnte. Falls Rückfragen sind, ist das kein Problem, solange Du sie nicht mit "Das ist Unfug" einleitest. Auf freundlich gestellte Fragen reagiere ich deutlich positiver als auf "Das ist Unfug", wenn "Das ist Unfug" Unfug ist und nichtmals eine brauchbare Begründung zum Widerspruch gereicht wird.

Du meinst im Gegensatz zu so Aussagen wie "Listen sind langsamer"?

Xin schrieb:

hustbaer schrieb:

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Die Tage haben wir in einem anderen Thread festgestellt, dass die Herkunft bzw. Bedeutung von Wörtern sich nicht in einer Umfrage erklären lässt, sondern eher durch Recherche.

Ansonsten haben wir nämlich genau das, was Mr. N schreibt: schwammige Begriffe, weil jeder ihn nach seiner subjektiven Meinung auslegt.
Davon gibt es mehr als genug in der Informatik, doch OOP gehört eigentlich nicht dazu.

Doch. Aber ich denke Hustbaer wollte, dass wir unsere Definitionen darlegen um nicht aneinander vorbei zu reden.

tntnet

Xin schrieb:

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

(Oder) gilt es heute wirklich schon als Diskussionsargument, wenn man die Aussage des Vorredners wiederholt und behauptet, man würde ihm so widersprechen?

Lies doch nochmal nach, wogegen Du widersprichst:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

ok - ich habe mir das nochmals durchgelesen. Ich wollte der ersten Aussage wiedersprechen, daß Arrays schneller sind. In vielen Fällen stimmt das, aber nicht immer. Daher kann man das so global nicht sagen. Das wollte ich durch ein Beispiel erläutern.

Und ich arbeite nicht im Marketing, sondern bin Softwareentwickler. Daher mache ich mir Gedanken über Algorithmen und Datenstrukturen und kann solch eine Aussage "Arrays sind schneller", die eher von einem Marketingmenschen stammen nicht einfach so stehen lassen.

Undertaker schrieb:

tntnet schrieb:

Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

was bestimmt oft schwieriger ist als in C.

und genau das ist nicht der Fall. Eine std::list ist genauso leicht zu verwenden, wie ein std::vector oder ein einfaches Array. Eine Liste in C ist immer schwieriger. Selbst wenn man was fertiges nimmt, harmoniert das nie so gut mit dem System, wie eine std::list. Man denke nur z. B. an Typsicherheit.

Undertaker

tntnet schrieb:

Undertaker schrieb:

tntnet schrieb:

Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

was bestimmt oft schwieriger ist als in C.

und genau das ist nicht der Fall. Eine std::list ist genauso leicht zu verwenden, wie ein std::vector oder ein einfaches Array. Eine Liste in C ist immer schwieriger. Selbst wenn man was fertiges nimmt, harmoniert das nie so gut mit dem System, wie eine std::list. Man denke nur z. B. an Typsicherheit.

ich dachte es geht dir um effizienz (wegen performacemythen und so) und nicht um austauschbarkeit mit arrays etc.
und da gibt es ganz schicke listenstrukturen in C, die z.b. nur aus ein paar makros bestehen und keine interne speicherverwaltung haben (und die man übrigens auch in c++ benutzen könnte). klar, typsicherheit ist dabei gleich null, aber dafür ist es eben rasend schnell.

scrub

Xin schrieb:

Objektorientiert wird das ganze in dem Moment, wo es eben nicht mehr um die Klasse, sondern um die Klasseninstanz - das Objekt - geht. Eine Katze ist eine Instanz der Klasse Tier und genauso eine Instanz der Klasse Lebewesen. Da jedoch nicht mehr alleine auf die Klassifizierung Wert gelegt wird, sondern man sich am wirklichen Typ der Datenstruktur - des Objektes - orientiert, verhält sich ein Objekt Katze der Klasse Tier wie eine Katze, genauso wie ein Objekt Katze der Klasse Lebewesen sich wie eine Katze verhält.
Man arbeitet objektorientiert und damit sich das von klassenorientierter Programmierung unterscheidet, nehme man in C++ das Schlüsselwort "virtual".

Wenn ich Dich also recht verstehe, wird klassenorientierte Programmierung dann zu objektorientierter, wenn die Klassen tatsächlich genutzt werden, um Objekte zu erstellen? Klingt für mich (als Anfänger/Laie) recht faszinierend. Wie oft programmierst Du Klassen, ohne daß diese später instanziert werden?

Xin schrieb:

Eine "class" ist eine Struktur mit einem eigenen Namensraum und beim Aufruf von Methoden steht das erste Argument links vom Methodennamen. Mehr ist das nicht und solange da kein virtual drin steht, ist es problemlos und ohne Aufwand in C abzubilden, weil man keine OOP Unterstützung benötigt.

Kannste ja auch anders sehen: Auch C unterstützt ein bißchen OO, aber nicht so viel bzw. gar nix.

Deine Definition von OO klingt sehr merkwürdig und ich habe sie auch noch nie gehört (da scheine ich ja nicht der einzige zu sein).

Undertaker

scrub schrieb:

Wenn ich Dich also recht verstehe, wird klassenorientierte Programmierung dann zu objektorientierter, wenn die Klassen tatsächlich genutzt werden, um Objekte zu erstellen? Klingt für mich (als Anfänger/Laie) recht faszinierend.

...aber wo er recht hat, hat er recht
--> http://en.wikipedia.org/wiki/Prototype-based_programming

Shade Of Mine

scrub schrieb:

Deine Definition von OO klingt sehr merkwürdig und ich habe sie auch noch nie gehört (da scheine ich ja nicht der einzige zu sein).

Jede konkrete Definition von OOP ist schwachsinn. Lest euch den Link von MrN durch: http://paulgraham.com/reesoo.html

Es gibt einen Haufen Sachen die Teil der OOP sind, aber man sie dennoch nicht braucht um OO zu programmieren.

@Xin: ich brauchte zB keine Klassen für ein OOD und genau da scheitert dein Ansatz. Es wirkt als hättest du alles rein auf C++ bezogen. Aber C++ bietet nur einen Teil der Features die jemand unter OOP verstehen könnte. Das merkt man schon alleine daran, dass ein Java Programm komplett anders aussieht als ein C++ Programm - obwohl die Syntax ähnlich ist und beide das OOP-Paradigma verwenden.

Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser.

@Undertaker: Themenverfehlung. Prototype Sprachen haben keine Klassen.

Findet ihr auch, dass man merkt, ob einer sein Wissen größtenteils aus Büchern hat.

Undertaker

Shade Of Mine schrieb:

@Undertaker: Themenverfehlung.

ja, hast recht. mit performancemythen hatte das nichts zu tun.

Xin

Mr. N schrieb:

Xin schrieb:

Klassenbasiert ist alles, was mit Datenstrukturen zu tun haben, die ausschließlich auf den aktuell verwendeten Datentyp - eben die Klasse - fixiert sind und Daten eben klassifizieren. Du könntest Dir in dem Zusammenhang kurz Gedanken machen, warum das Schlüsselwort in allen gängigen Sprachen "class" heißt und nicht "object".

Weil die Instanz das Objekt ist.

Richtig. Ein Objekt für das ich mich bei klassenorientierter Programmierung nicht die Bohne interessiere, es ist mein Datensatz und wenn das Vieh in Wirklichkeit ein Auto muss das Auto eben ab sofort Traubenzucker verbrennen.
Ich orientiere mich nicht am Objekt, sondern an dem Datentyp mit dem ich grade dahin referenziere.

Tier * tier = new Katze();
tier->NichtVirtuelleFunktion();

Hat Katze NichtVirtuelleFunktion überladen, interessiert keine Sau, dass das Objekt tier eine Katze ist. Man orientiert sich an der Referenz-Klasse, nicht am Objekt => nicht objektorientiert.

Fällt Dir auf, wie der sich der Begriff objektorientiert, der in OOP abgekürzt wird, hier wieder findet?
Wenn wir von OOP sprechen, heißt das eben nicht OOPUVVKMDHUVM. (objektorientierte Programmierung unter Verwendung von Klassen mit DataHiding und vielem mehr). Wenn wir den OOPUVVKMDHUVM definieren wollen, dann würde ich Dir uneingeschränkt reicht geben. Der Punkt heißt aber nur und ausschließlich "objektorientiert".

Mr. N schrieb:

Xin schrieb:

Katzen gehören zur Klasse der Tiere, welche zur Klasse der Lebewesen gehören. Bis hierhin gibt es noch nichtmal ein Objekt, keine existierende Katze, kein existirendes Tier, lediglich die Feststellung, dass derartige Objekte - sollten sie irgendwann existieren - irgendwie klassifiziert werden und dass zwischen Katzen und Tieren eine gerichtete Verbindung besteht.
Beim Zugriff auf die Objekte orientiert sich die Sprache an der Klasse, die man zur Zeit betrachtet. Ein Tier ist eine andere Klasse als eine Katze und Tiere machen alles wie Tiere und Katzen machen alles wie Katzen. Katzen sind Tiere und eine Objekt, das als Tier aufgefordert wird etwas zu tun, interessiert sich nicht die Bohne, dass Katzen das lieber anders machen würden.
Alles statisch, eben nicht objektorientiert, aber eben mit 'class'es klassifiziert.

Objektorientiert wird das ganze in dem Moment, wo es eben nicht mehr um die Klasse, sondern um die Klasseninstanz - das Objekt - geht. Eine Katze ist eine Instanz der Klasse Tier und genauso eine Instanz der Klasse Lebewesen. Da jedoch nicht mehr alleine auf die Klassifizierung Wert gelegt wird, sondern man sich am wirklichen Typ der Datenstruktur - des Objektes - orientiert, verhält sich ein Objekt Katze der Klasse Tier wie eine Katze, genauso wie ein Objekt Katze der Klasse Lebewesen sich wie eine Katze verhält.
Man arbeitet objektorientiert und damit sich das von klassenorientierter Programmierung unterscheidet, nehme man in C++ das Schlüsselwort "virtual".

Ich stimme deiner Definition nicht zu. Encapsulation geht auch ohne Polymorphie und ist doch sehr objektorientiert. Aber da möchte ich dir nochmal den Link von oben ans Herz legen. In diesem Link wird OOP zunächst in mehrere Aspekte aufgeteilt und verglichen, welche der existierenden Varianten von OOP welche Aspekte beherrscht. Meine Konsequenz aus dem Artikel war, OOP möglichst breit zu fassen. Du hingegen definierst OOP als "virtual-Methoden", und das halte ich für gefährlich und falsch.

Meine Konsequenz aus dem Artikel ist, dass Paul Graham hier Dinge, die notwendig sind, um OOP zu betreiben, wie zum Beispiel Klassifizierung aber auch unnötige Techniken wie Überladung als OOP verkauft. Ohne Klassifizierung gibt's kein OOP, aber ohne OOP gibt Klassifizierung. Klassifizierung geht auch ohne "class", aber "class" ist praktisch, weil es wie geschaffen dafür ist, Datenstrukturen einfach zu klassifizieren. Das wiederum könnte daran liegen, dass "class" dafür geschaffen wurde...
Das ist eine Frage der Abhängigkeit von Techniken, aber kein Grund alles in einen Topf zu werfen, OOP auf den Deckel zu stempeln und das als die Wahrheit zu verkaufen.
Die Sichtbartkeit von Daten ist ein gutes Feature. OOP funktioniert problemlos, wenn alle Informationen public sind. Die Möglichkeit es einzuschränken ist also keine Vorraussetzung für OOP und DataHiding funktioniert auch problemlos mit Objekten, wo sich der Programmablauf nicht am Objekttyp orientiert.
DataHiding ist einfach eine andere Baustelle.

Mr. N schrieb:

Xin schrieb:

Eine "class" ist eine Struktur mit einem eigenen Namensraum und beim Aufruf von Methoden steht das erste Argument links vom Methodennamen. Mehr ist das nicht und solange da kein virtual drin steht, ist es problemlos und ohne Aufwand in C abzubilden, weil man keine OOP Unterstützung benötigt.

Man kann auch in C, sogar mit structs, objekt-orientiert programmieren, aber wir haben da ja einen definition-mismatch.

Haben wir in dem Punkt nicht, weil das genau das ist, was ich grade geschrieben habe.
In C gibt es keine Klassen (aber dennoch die Möglichkeit zur Klassifizierung) und es gibt kein DataHiding und Du stimmst grade zu, dass OOP unabhängig davon geht, was bedeutet, dass DataHiding und Klassen für OOP nicht erforderlich sind.
Wir sind uns also einig und Du widersprichst Deiner vorherigen Aussage.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

In gewissen Fällen muss der Compiler die virtuelle Methode nicht indirekt aufrufen.

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Ansonsten bin ich neugierig, was jetzt kommt.

Geballte Kompetenz kommt jetzt.
Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Wenn Du mir widersprechen willst, solltest Du nicht wiederholen, was ich einen Satz dadrüber geschrieben habe.
Aber Du bist ja nicht der einzige in dem Thread mit einem derartigen Argumentationsstil.

Deine geballte Kompetenz ist ein Plagiat und damit ein Griff ins Klo. Wenn das alles war, war das als Argument wirklich beeindruckend. Deine geballte Kompetenz reichte leider nicht, um korrekt abzuschreiben, denn Du hast leider die Zusatzbedingung vergessen, dass sichergestellt sein muss, dass von der Klasse keine Ableitung existiert. Damit hat sich Deine geballte Kompetenz leider als doppelter Griff ins Klo erwiesen.
Herzlichen Glückwunsch.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Besteht für dich alles nur aus Implementierungsphilosophie? Doch, wenn ich eine Zahlen-Klasse habe, würde ich das meistens OOP nennen. (Wobei in C++ die Grenzen verwischen.)

Meistens? Mal ja, mal nein? Natürliche Zahlen haben nur ein bißchen OOP, Komplexe sind kompliziert, deswegen müssen die in OOP geschrieben werden?
Wovon hängt das ab? Uhrzeit? Tagesform? Wetter?

Der Witz ist, dass meine Zahlenklasse (nennen wir sie rational) sich wie eine Zahl verhält, nach außen hin, die Implementierung aber austauschbar und egal ist.

Das ist ja klasse! Und man braucht noch nichtmals OOP dafür, da die Überladung des operator int() rein statisch abläuft. Klassenbasiert und eben nicht objektorientiert.

Mr. N schrieb:

Xin schrieb:

In C++ verwischen Grenzen? Ist OOP in C++ was anderes als in Simula, Java, oder warum verwischen Grenzen grade in C++?

C++ is a Multi-Paradigm Language.

Und weil C++ mehr als nur OOP kann, ist OOP in C++ etwas vollkommen anderes als in anderen Sprachen oder wie soll ich das verstehen?

Mr. N schrieb:

Xin schrieb:

Wenn ich eine Klasse habe, würde ich von einer Klasse sprechen. Darum heißen die Dinger Klassen, vermute ich.
Ein Instanz einer Klasse ist ein Objekt - wie auch ein Array, ein Integer und alles, was aus mehr als void besteht.

Er benutzt schon selber das wort Objekt. (Ja, ich habe den nächsten Abschnitt gelesen. )

Yepp, und zwar bewußt, da alles ein Objekt ist. Daher das Wort "Objekt". Nur mal kurz überlegen, was "Objekt" bedeutet. Objekte hat man im Schrank stehen: Bücher, Kerze, Uhr, Teelicht. Oder in der Kunstausstellung: Bild, Statue, Teebeutel. Objekt ist ein hübscheres Synonym für "irgendein Ding".

Nochmals: Egal, selbst wenn ein Paul Graham behaupten würde, dass ein Objekt nur etwas sein kann, was mit class definiert ist (was er nicht tut!), ist das Quatsch. Ein Datensatz - egal, wie er entstanden ist, ob als Struct, als Integer, als Array von Chars oder als Class ist ein Objekt.

Ein int[4] ist exakt das Gleiche wie ein

class FooBar
{
  int Eins, Zwei, Drei, Vier;
};

Es sind vier Zahlen, die etwas repräsentieren. Bei einer Klasse oder einem Struct darf den einzelnen Elementen auch noch Namen geben. Dem Datentyp könnte man notfalls mit typedef einen Namen geben.

Da kommt Java an und macht den OOP-Hype und erklärt alles, was nicht von "class object" abgeleitet ist, steht für böse Magie, weil das darf ja kein Objekt mehr sein und auf einmal stellt jeder das Denken ein.
Was in Java nicht von "object" abgeleitet ist, ist keine Instanz von "class Object", das ist nicht gleichbedeutend mit "ist kein Objekt". Das sprechen eure Profs vielleicht nicht sauber aus, vielleicht glauben sie sogar, dass ein int kein "irgendein Ding" ist, aber mit ein wenig gesunden Menschenverstand, kapiert man doch, das alles, was nicht nichts (void) ist, eben "irgendein Ding" (Objekt) ist.

Wenn man nun das Denken eingestellt hat und merkt, dass man zwischen Klassenorientiert und Objektorientiert nicht mehr unterscheiden kann, dann kann man entweder das Denken wieder anwerfen oder Sonderbedingungen suchen, z.B. Ein Objekt ist irgendein Ding, dass aber kein char, kein int, kein Array, kein Struct, kein was auch immer ist, sondern eine Klasseninstanz ist.

Hätte man so gedacht, als OOP erfunden wurde, hätte man es klasseninstanzorientiertes Programmierung genannt.
Ist es denn wirklich so schwer, sich die Bedeutung der Worte 'objekt orientiert' mal bewußt zu machen?

Programmiert man objektorientiert, arbeitet man weiterhin mit Objekten, die allerdings zusätzlich eine Typinformation enthalten im Datensatz enthalten, an der sich die Algorithmen orientieren können. In dem Fall ist int[4] eben mehr nicht identisch mit

class FooBar
{
  int Eins, Zwei, Drei, Vier;
  virtual ~FooBar();
};

Mr. N schrieb:

Xin schrieb:

Wenn sich das Programm am Datentyp der Klasse orientiert, nenne ich das klassenorientiert.
Wenn sich das Programm am Datentyp des Objektes orientiert, nenne ich das objektorientiert.

Ich stimme nicht zu.

Ja, wenn Du nicht zustimmst, dann muss ich mich geirrt haben.
Dagegen gibt's auch nichts mehr zu sagen, schließlich ist neben der Allwissenheitsvermutung ansonsten weit und breit kein Argument zu sehen.

Mr. N schrieb:

Wenn ich eine andere Definition habe als du bringt das nix. (Und meine ist von mehreren Links gedeckt, falls dir mein Wort nichts bedeutet.)

Mir bedeutet Logik etwas. Daran halte ich mich. Solange Du nicht mehr zu bieten hast als "Ich stimme nicht zu" und in Deinen Quellen nicht das "Warum" zitieren kannst, bedeutet mir Dein Wort genausowenig wie die Links.

Ich ärgere mich ehrlich gesagt darüber, dass ich mir viel Mühe gebe, das "Warum" zu erklären und dann kommen Argumentationen, die meinen Text abschreiben und behaupten, dass wäre ein Gegenargument oder ein "Ich stimme nicht zu". Wenn Du diskutieren willst und etwas behaupten willst, mach Dir wenigstens die Mühe das "Warum" zu Deiner Behauptung mitzuliefern. Ansonsten kann ich auch die Bildzeitung aufschlagen.

Es ist für mir nicht wichtig, Dich zu überzeugen, Du darfst glauben, was immer Du möchtest. Du darfst mir auch gerne etwas neues beibringen. Aber das funktioniert nicht allein mit Behauptungen oder Behauptungen anderer. Quotes konnte ich genauso beibringen und eine Zitateschlacht hilft nichts, denn wir werden nach belieben Behauptungen für jeden Mist finden, die wir zitieren können. Du vermutlich mehr als ich.

Aber weiterbringen wird uns das wirklich nicht, denn ohne eine klare Erklärung des "Warums", wirst Du meine Ansicht nicht kippen können. Was ich hier erläutere, habe ich genauso schon mit Stroustrup belegen können, der das "Warum" von C++ einen Wälzer ausführlich in 550 Seiten, von denen ich jede einzelne Seite gelesen und nachvollzogen habe. Für mich ist die Frage, des "Warums" wirklich sehr erschöpfend beantwortet.
Aber ich kann Dir auch sagen, dass ich vor acht, neuen Jahren vermutlich noch genauso argumentiert hätte wie Du.
Ich sehe, dass ich mit meinem Verständnis einen Schritt weiter gekommen bin. Ich bin den Schritt bewußt gegangen und solange Du nicht wirklich extremst gute Argumente bringst, die ich noch nicht kenne, weiß ich, dass richtig liege. Das wird Dir nämlich nicht gelingen.
Ich liege richtig, unabhängig davon, was in Wikipedia steht, unabhängig davon, wieviele Leute das in diesem Forum anders sehen. Das hat auch nichts mit Sturheit zu tun, sondern eben mit der Tatsache, dass ich von Deinem Point of View mich in den letzten Jahren durch die Entwicklung meines Compilers und das Lesen von entsprechender Fachliteratur auf meinen Point of View bewegt habe.

tntnet schrieb:

ok - ich habe mir das nochmals durchgelesen. Ich wollte der ersten Aussage wiedersprechen, daß Arrays schneller sind. In vielen Fällen stimmt das, aber nicht immer. Daher kann man das so global nicht sagen. Das wollte ich durch ein Beispiel erläutern.

Das ist soweit löblich, aber was mich hier - genauso wie jetzt bei MrN - wirklich nervt ist die Tatsache, dass sich so ein Pulk aufbaut, wo jeder meint, dass ich Unfug schreibe, obwohl Dein Argument in meiner Aussage längst berücksichtigt ist.

Hier haben wir den nächsten Kandidaten:

Shade Of Mine schrieb:

@Xin: ich brauchte zB keine Klassen für ein OOD und genau da scheitert dein Ansatz.

Wiederhole ich mich darin, wenn ich schreibe, dass man nicht gegen mich Argumentiert, wenn man meine Argumentation abschreibt?

Damit sind jetzt drei Leute, die meine Aussage abschreiben und behaupten, sie würden mich damit widerlegen.
Wozu erkläre ich es eigentlich so deutlich, wahrscheinlich, um mir als nächstes anzuhören, dass weil ich es erkläre, hat keiner Bock es zu lesen und widerspricht einfach mal, weil andere widersprechen ja auch.

Sorry, aber wenn die Dinge so diskutiert werden, da frage ich mich doch, in welchem Kindergarten ich gelandet bin.

Das Resultat ist dann sowas, wo jemand feststellt, dass ja alle gegen mich argumentieren, die breite Masse wirds ja wissen, also muss, was ich schreibe ja Unfug sein...

scrub schrieb:

Deine Definition von OO klingt sehr merkwürdig und ich habe sie auch noch nie gehört (da scheine ich ja nicht der einzige zu sein).

...statt sich davon zu Befreien, was irgendwer definiert und sich selbst Gedanken zu machen, was denn eigentlich logisch ist. Für OOP reichen Objekte allein eben nicht. Man muss sich halt auch wirklich darum kümmern, um welchen Objekttypen es sich handelt, darum steht das zweite O für Orientierung. Dafür braucht man keine Klassen, kein Encapsulation und keine DataProtection, dafür braucht man Vererbung und das geht genausogut mit Structs oder Arrays - nur halt nicht so komfortabel wie mit Klassen.

lieber Xin,

dein(e) post(s) auf seite 8 sind leider von vorne bis hinten grober unfug (dein letzter post vor meinem hier ist nur reines rumgetrolle darum werde ich auf den nicht eingehen)
wenn ich mich richtig erinnere bist du auch derjenige, der damals felsenfest den standpunkt "Phantasie ist wichtiger als Wissen" vertreten hat. Offentsichtlich lebst du diesen standpunkt hier mit vergnügen aus. Dennoch wär es von vorteil wenn du dir mal ein bisschen *Wissen* über Objektorientierte Programmierung aneignest, denn OOP ist *definiert*. /deine/ definition ist leider nur *phantasie*. deshalb brauchst du dich auch nicht wundern dass hier alle außer dir eine andere (nämlich *die*) definition von oop anwenden. wenn du deine oop-definition als "das wahre" verkaufen willst schreib ein buch oder werd priester.

gruß,
gurkenesser

PS: warum du hier versuchst mit Bjarne Strostrup zu argumentieren verstehe ich übrigens auch nicht.

Alan Kay schrieb:

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.