Performancemythen?
-
DEvent schrieb:
Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.Yo lassen wir das, ich geb mich geschlagen.
f(x) = ax+b.
Unabhängig davon, ob man a=k setzt oder b=k, die Funktion bleibt linear von x abhängig ist. Darum geht's bei der O-Notation. Kommen mehr Daten hinzu, ändert sich das Laufzeitverhalten nicht n^2 oder n log n oder sonst was.
O( n ) = O( a*n ) = O( n+b ) = O( a*n+b ).
Pro Datensatz steigt die Laufzeit linear. Fertig.Davon unabhängig bedeutet k aber, dass der Anwender k * länger pro Datensatz warten muss. Den wird das schon nerven und er wird sich für das Produkt entscheiden, dass die Antwort schneller findet.
Danke, ich kann wohl doch besser JavaScript als du
Ich schreibe Compiler, keine Websites. Ich hoffe für Dich, dass Du JS besser kannst als ich.
Shade Of Mine schrieb:
In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?
Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.
Begründe das.
Shade Of Mine schrieb:
Beantworte mir also bitte die Frage:
warum ist Lisp kein OO? Warum sind Klassen und Vererbung besser als Prototypes und Objekt klonen? Warum sind virtuelle Funktionen besser als Multimethods?Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.
Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.
Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.Shade Of Mine schrieb:
Solange du das nicht beantworten kannst - ist deine OO Argumentation Fehlerhaft, weil sie viele Aspekte einfach ignoriert.
Fragen beantwortet, obwohl sie teils "Warum ist es nachts kälter als draußen?" Charakter haben. Hast Du noch mehr Fragen?
Shade Of Mine schrieb:
Der Ausdruck mit Nachrichten ist nichts anderes als eine Formulierung um zu betonen dass es um die Objekte geht die das Verhalten bestimmen.
...der nächste, der abschreibt, was ich sage und es als Argument verwenden möchte... Du bist #4 in diesem Thread, denkt euch doch mal was neues aus.
Shade Of Mine schrieb:
Aber der Punkt ist ja: wir behaupten man kann sie nicht genau definieren weil sie eine denkweise ist und klammerst dich an C++ und Java um OOP zu definieren. Dabei ignorierst du, dass es komplett andere Sprachen gibt die ebenfalls OOP Konzepte anbieten.
Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.
Sprachen neben C++ oder Java machen mir keine bisher Probleme. Mal eben "LISP" einzuwerfen ohne etwas konkretes zu aufzeigen, was meiner Aussage widerspricht, ist dafür etwas wenig.
Zumal Du erstmal Deine Definition an C++ belegen darfst - ich erinnere an die immernoch nicht beantwortete Frage von mir.
Wenn meine Definition auf LISP nicht passen würde, dann wäre das schlecht, aber die "Standard"-Definition passt nichtmals auf C++.Shade Of Mine schrieb:
In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?
Überladene Funktionen sind Funktionen gleichen Namens aber unterschiedlicher Signatur. Sie sind damit vom Compiler problemlos zu unterscheiden. Statische Funktionen sind grundsätzlich nicht objektorientiert, sie sind eben statisch. Und sie bleiben statisch, wenn sie in einem anderen Namespace liegen. Ich sehe da eine ganz klare Grenze, die absolut keine Frage läßt: nicht OOP.
Shade Of Mine schrieb:
Ist statische Polymorphie keine echte Polymorphie weil zur Laufzeit nichts geänedert werden kann? Aber Java geht noch weiter: man kann die Klassen zur Laufzeit erst _erstellen_. Etwas das in C++ nicht geht. Ist jetzt die dynamische Polymorphie in C++ weniger Polymorph als in Java? Denn Java bietet eine deutlich bessere Laufzeit Polymorphie was die dynamik betrifft. Wo genau trennt man da?
Der Spaß heißt Reflection. Falsche Baustelle.
Templates können auch objektorientierte Klassen erstellen - müssen es aber nicht. Weder brauchst Du Templates oder Reflection für OOP, noch OOP für Templates oder Reflection. Du darfst sie aber gerne zusammen verwenden.
-
Xin schrieb:
Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.
Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.Xin schrieb:
Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.
Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?
-
scrub schrieb:
Xin schrieb:
Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.
Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.Ich gehe mal davon aus, dass Du absichtlich im Dreiersystem rechnest und nicht im Zweiersystem, um 4 auszudrücken.
Wenn nicht, solltest Du überlegen, ob Du Dich mit Deiner Meinung nicht zu schnell festgelegt hast.
scrub schrieb:
Xin schrieb:
Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.
Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.
Wenn Du OOP so definierst, brauchst Du keine Definition, Du kannst auch einfach Programmiersprache sagen, das wäre gleichwertig.
-
Xin schrieb:
Shade Of Mine schrieb:
In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?
Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.
Begründe das.
Vorher die Frage, ob du jemals mit Smalltalk gearbeitet hast.
Xin schrieb:
Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.
Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.
Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Multimethoden werden dynamisch dispatched, im gegensatz zu deinem operator+ in C++.
Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?
Warum gerade LISP? Er hätte auch Dylan nehmen können. Es geht eben darum, das jede beliebige Funktion dynamisch dispatchen kann.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.
MAchen wir mal konkrete Beispiele: Es gibt Sprachen, in denen die Punkt-Notation zum Methodenaufruf nur Syntax-Zucker ist.
object.methode(argument)und
methode(object, argument)sind dort beides gültige Schreibweisen und beide haben natürlich das selbe Laufzeitverhalten. Es ist ja auch nur ne andere Syntax, sonst nix. Man kann aber auch sagen, dass außedem auch anhand des Typs des "zweiten" Arguments (hier 'argument') dynamisch zu dispatchen. Und schon hat man eine Multimethode.
Ich kann die Methoden innerhalb der Klasse definieren oder außerhalb. Beide erlauben die selbe Aufrufsyntax, beide dispatchen gleichermaßen dynamisch. Lediglich die zugriffsrechte auf Private Teile der Klasse sind unterschiedlich.
Das nur vielleicht als Horizont-Erweiterung.
Templates können auch objektorientierte Klassen erstellen
Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.
-
Xin schrieb:
Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.
In wie weit unterstützt mich Assembler denn dabei diese Art zu denken auch einzusetzten?
Ermöglichen != Unterstützen.
-
asc schrieb:
Jester schrieb:
edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.
Mal davon Abgesehen das auch in C++ das "StringBuffer"-Problem bestand. Den bei vielen Stringadditionen nutzt man auch unter C++ eher ein entsprechendes Streamobjekt.
Das sind komplett unterschiedliche Problematiken. std::string ist eher vergleichbar mit StringBuffer nur dass es keine "string+int"-Overloads gibt, daher wird zum Bauen von Strings mit Zahlen etc. ein anderes Mittel nötig. stringstreams eben.
asc schrieb:
Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.
Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.
-
Xin schrieb:
Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.
Wenn Du OOP so definierst, brauchst Du keine Definition, Du kannst auch einfach Programmiersprache sagen, das wäre gleichwertig.
Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen. Aber das gilt doch für alle Paradigmen.
( "Ein Geisterfahrer?! TAUSENDE!"
)Mr. N schrieb:
asc schrieb:
Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.
Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.
Er spricht von dem Performance-Artikel (so habe ich es zumindest verstanden).
-
Helium schrieb:
Xin schrieb:
Shade Of Mine schrieb:
In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?
Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.
Begründe das.
Vorher die Frage, ob du jemals mit Smalltalk gearbeitet hast.
Nein.
Helium schrieb:
Xin schrieb:
Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.
Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.
Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Multimethoden werden dynamisch dispatched, im gegensatz zu deinem operator+ in C++.
Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.
Helium schrieb:
Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?
Wo steht, dass ich was gegen JavaScript habe? Und selbst wenn, was hat es mit OOP zu tun?
Helium schrieb:
Templates können auch objektorientierte Klassen erstellen
Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.
Ansonsten möchte ich das gerne umformulieren, bevor jemand einwendet, dass Klassen nicht objektorientiert sein können, da sie nur eine Beschreibung darstellen: Templates können auch Klassen erstellen, die Objekte erstellen, die sich zur objektorientierten Programmierung eignen.
Müssen sie aber nicht.
-
Xin schrieb:
Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.
Ich wette, dass sich die Entwickler von z.B. Sun krummlachen, wenn ich an die herantrete und behaupte, dass ihre String-Klasse nicht objektorientiert sei, da man keine Methoden überschreiben kann. Eine komische Definition von OOP, die du da hast. Es ist ja aber weitläufig bekannt, dass Java eine Multi-Paradigma-Sprache ist, immerhin unterstützt sie objektorientierte und klassenorientierte (!) Programmierung.
-
Xin argumentiert zwar als einziger hier überzeugend - aber vielleicht sollte man sich dennoch auch mal ansehen, wie Bjarne Stroustrup Objekt-Orientierung definiert. Schließlich beruft sich Xin auch auf ihn.
Stroustrup definiert OOP nach obigem Link als:
1. Kapselung/Abstraktion
2. Vererbung
3. Laufzeit-PolymorphieDamit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht. Denn ohne Laufzeit-Polymorphie ist das Kriterium der Objekt-Orientierung eben nicht vollständig erfüllt.
Sehr schön ist übrigens auch das Beispiel, welches Stroustrup dort anführt
rüdiger schrieb:
Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen.
Davon abgesehen, dass du eine Erklärung für deine Aussage schuldig bleibst, erzwingt sie geradezu ein Zitat aus dem Paper, welches Stroustrup bei der OOP-Definition verlinkt:
A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction – providing some form of classes and objects.
[2] Inheritance – providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism – providing some form of run-time binding.
-
minhen schrieb:
Xin argumentiert zwar als einziger hier überzeugend
Schön, dass du den ganzen Thread gelesen hast.
-
scrub schrieb:
Xin schrieb:
Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.
Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?Ich habe diesen Thread jetzt 17 Seiten lang gelesen und langsam wird es mir zu blöd.
Man muss doch drei Dinge einsehen können.
-
Die Definition, die du für OOP benutzt, ist nicht die gängige. Du nimmst einen Teil dessen, was allgemein als OOP verstanden wird (virtuelle Methoden, bzw. Polymorphie, virtuelle Methoden sind ja praktisch nur ein Implementierungsdeteil, um Polymorphie zu erreichen) und definierst das als das einzig und allein von OOP bezeichnete. Das ist aber im üblichen Sprachgebrauch nicht so. Dort ist es nämlich so, dass der Begriff OOP sehr viele verschiedene Dinge wie Kapselung, Polymorphie, Typsicherheit und vor allem die Zusammenlegung von Daten und Funktionen zu einem Datentyp bezeichnet. D.h. es existieren nicht getrennt Daten und Funktionen, sondern man schreibt eine Klasse, die sowohl die Daten als auch die Methoden, d.h. die Funktionalität der Objekte der Klasse bestimmt.
-
Du reitest darauf herum, dass es OBJEKT-orientier heißt, und hälst anderen vor, dass bei allen Bestandteilen der OOP (nach meinem Verständnis) kein OBJEKT benutzt/gebraucht wird, weil der dynamische Typ nicht gebraucht wird. Was man aber sehen muss, ist das jedes Objekt auch einen STATISCHEN TYP hat. Und auf den kann man sich doch mit dem gleichen Recht wie auf den dynamischen beziehen und das ganze dann Objektorientiert nennen.
-
Warum dir keiner WIRKLICH widerspricht: Es ist halt (wie oben gesagt) so, dass OOP sehr unscharf definiert ist und deswegen kann man kein Zitat finden, dass dir explizit widerspricht (auch wenn ein paar Quellen ja in die Richtung gehen). Aber deine bisher gebrachten Zitate/Quellen untersützten deine Meinung auch nicht wirklich.
Um nur mal ein Beispiel zu bringen, ein Zitat aus Marc++us Buch, welche Konzepote alle unter OOP verstanden werden:
Objekte, Klassen, Vererbung, Polymorphie, Späte Bindung, Kapselung.
Das 2. Kapitel in genau dem Buch heißt übrigens "Wieso eigentlich nicht 'klassenorientierte Programmierung'". Eine wirkliche Antwort darauf wird allerdings auch nicht gegeben
Es liegt halt daran, dass man das Verhalten von Objekten in der OOA analysiert, um daraus Klassen zu abstrahieren und nachher wieder mit OBJEKTEN dieser Klasse arbeitet. Ohne irgendwelche Instanzen nutzen die schönsten Klassen nichts (oder sind nicht mehr als namespaces)...Wenn das jetzt auch nicht reicht, Pech gehabt... Irgendwann muss das hier doch mal ein Ende haben. Sonst wälze ich gleich auch noch den Struppi und suche ein vernünftiges Zitat, das die gängige Fassung belegt.
Mehr als diese Erklärung und die gängige Meinung + Belege dafür kann man wirklich nicht verlangen, um von der Haarspalterei um die OBJEKT anstatt Klassen orientierte Programmierung wegzukommen...
Um nochmal darauf hinzuweisen: Es geht hier eigentlich um "Performancemythen". Dazu steht auch etwas schönes in Marc++us Buch:
Haben Sie auch schon davon gehört, dass C++ langsam ist, weil man nie direkt auf die Variablen zugreift? Unsinn, lassen Sie sich davonkeine Angst machen. Der Zugriff mit einer kleinen kurzen get-Methode auf eine Variable wird von einem optimierenden Cimpiler so gut übersetzt, dass es nur einige Taktzyklen länger dauert, als direkt auf die Variable zuzugreifen. Es gibt keinen Grund, wegen der Rechenzeig hier einen Kompromiss einzugehen, dies ist am falschen Ende gespart.
Dazu kommt natürlich auch noch inline + Optimierungen, sodass im besten Fall sogar gar keine Methode aufgerufen wird...
Endlich mal wieder Ontopic (obwohl die Ausschweifung mit der Komplexität und der O-Notation ja auch relativ on-topic war).
Vielleicht sollte mal wer ein Gesetz aufstellen, dass das auftreten eines Flamewars in Abhängigkeit der Benutzer eines Forums beschreibt. So was ähnliches wie Godwins Gesetz.
Felix
-
-
minhen schrieb:
Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht.
-
minhen schrieb:
Xin argumentiert zwar als einziger hier überzeugend
Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein. Standard-Definitionen bzw. Referenzen auf diese werden damit abgebügelt, dass man ja offensichtlich nicht in der Lage sei sich kritisch mit den Sachen auseinanderzusetzen. Das überzeugt mich zwar auch, aber von anderen Dingen als vom Autor vorgesehen.
-
Xin schrieb:
Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.
Meinst du den technischen Ablauf? Der ist doch von Sprache zu Sprache extrem verschieden. In statisch typisierten Sprachen habe ich ganz ander Optimierungsmöglichkeiten, z.B. mit virtuellen Methodentabellen, als z.B. in dynamisch typisierten Sprachen. Wenn ich Multimethoden unterstütze kann ich wieder anders vorgehen, jenachdem, wieviel Typinformation mir zur Compilezeit zur verfügung steht. ...
Xin schrieb:
Helium schrieb:
Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.
Was ist mit Sprachen, die nicht statisch typisiert sind? Keine Klasse muss von der anderen abgeleitet sein. Dennoch habe ich genau das Verhalten, das ich bei deinen virtuellen Methoden und abgeleiteten Klassen hätte. (Selbst statisch typisierte Sprachen unterstützen teilweise Ducktyping.)
Oder in prototypbasierten Sprachen. Ich klone ein Objekt, modifiziere die Methode des einen Objekts und schon habe ich auch das selbe Verhalten, ohne dass überhaupt eine Klasse vorgekommen ist.
-
minhen schrieb:
Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht. Denn ohne Laufzeit-Polymorphie ist das Kriterium der Objekt-Orientierung eben nicht vollständig erfüllt.
Falsch. In dem verlinkten Text von Stroustrup redet dieser von der C++ Sprache und _nicht_ von C++-Code. Er definiert dort erstmal nur ab wann sich eine Programmiersprache als Objektorientiert bezeichnen darf.
-
minhen schrieb:
Xin argumentiert zwar als einziger hier überzeugend - aber vielleicht sollte man sich dennoch auch mal ansehen, wie Bjarne Stroustrup Objekt-Orientierung definiert. Schließlich beruft sich Xin auch auf ihn.
Guter Link, hätte ich mal nach suchen sollen. Thx.
Phoemuex Post ist mir jetzt zu lang, um da was zu quoten. Zumal ich nicht weiß, wogen er argumentiert.
Er antwortet auf scrup, schreibt "Du" und das 1. und 3. Argument scheint gegen mich zu gehen.
Zu Punkt zwei möchte ich anmerken, dass ich darauf rumreite, dass es objektORIENTIERT heißt.Phoemuex schrieb:
Dazu kommt natürlich auch noch inline + Optimierungen, sodass im besten Fall sogar gar keine Methode aufgerufen wird...
Faktor 5-10. "Bestätigt", wie die Mythbuster so gerne sagen.
Jester schrieb:
minhen schrieb:
Xin argumentiert zwar als einziger hier überzeugend
Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein.
Argumente? Ich höre laufend "Ich finde..." und keinerlei Begründungen, warum diejenigen hier etwas verloren haben.4 Leute schreiben Aussagen von mir ab, behaupten, dass sie das Gegenteil bedeuten von dem, was da steht und darauf soll ich eingehen?
Bring erstmal ein Argument, auf das ich eingehen kann.
Ich sagte ja bereits, wo ich meine Ansicht kippen lassen würde.
Seit 7 Seiten frage ich in jedem zweiten Posting, dass man nur die Frage an hustbaer sinnvoll beantworten müsse. Bisher hat's noch nichtmals einer versucht.
-
Xin schrieb:
Phoemuex Post ist mir jetzt zu lang, um da was zu quoten. Zumal ich nicht weiß, wogen er argumentiert.
Er antwortet auf scrup, schreibt "Du" und das 1. und 3. Argument scheint gegen mich zu gehen.
Zu Punkt zwei möchte ich anmerken, dass ich darauf rumreite, dass es objektORIENTIERT heißt.Ich stimmte scrup zu und widerspreche damit dir. War ein bisschen unklar...
Felix
-
Helium schrieb:
Xin schrieb:
Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.
Meinst du den technischen Ablauf? Der ist doch von Sprache zu Sprache extrem verschieden. In statisch typisierten Sprachen habe ich ganz ander Optimierungsmöglichkeiten, z.B. mit virtuellen Methodentabellen, als z.B. in dynamisch typisierten Sprachen. Wenn ich Multimethoden unterstütze kann ich wieder anders vorgehen, jenachdem, wieviel Typinformation mir zur Compilezeit zur verfügung steht. ...
Bei objektorientiertem Problemstellungen ist der Punkt ja eben, dass die exakte Typ-Information eben nicht zur Compilezeit zur Verfügung steht. Darum OOP, weil Multimethoden eben nicht reichen.
Helium schrieb:
Ich klone ein Objekt, modifiziere die Methode des einen Objekts und schon habe ich auch das selbe Verhalten, ohne dass überhaupt eine Klasse vorgekommen ist.
Wie ich schon geschrieben habe: Klassen sind keine Voraussetzung für OOP. Sie sind eine Möglichkeit.
OOP geht problemlos mit nicht typisierten Sprachen, die keine Klassen verwenden.Ich mache jetzt C++-Forums-Feierband, heute sind keine Antworten mehr von mir zu erwarten.
-
Falls Du damit die Frage meinst warum OOP so heißt wie's heißt? Scrub hat's Dir schon gesagt. Aber Du wiederholst nur das was Du die ganze Zeit schon redest und vermutlich hat er ja auch noch bei Dir abgeschrieben.
Ich bestreite den Faktor 5-10. Her mit den Sourcen, dann schaun wir weiter.
