Performancemythen?

michba schrieb:

Die Fragen von Tim und Jester hast du übrigens auch noch nicht beantwortet.

Ich interpretiere die Nichtbeantwortung dieser fast-rhetorischen Fragen als Antwort auf eben jene

rüdiger

minhen schrieb:

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.

Um dir eine Erklärung zu geben, musst du mir erst einmal sagen, was du unter einer objektorientierten Programmiersprache verstehst. Also damit meine ich _nicht_, welche Eigenschaften die Programmiersprache unterstützen muss, sondern das "wie" und das "was bringt es".

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

(Stroustrup ist zwar ein sehr intelligenter Mensch und hat sehr viel Ahnung von Programmiersprachen-Themen. Aber deshalb ist er nicht mein Vordenker. Einfach nur auf Stroustrup zu verweisen und das als "Gesetz" hinzustellen, erklärt mir auch zu wenig...)

asc

rüdiger schrieb:

Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen.

Das würde ich nicht ganz unterschreiben, liegt aber vermutlich mehr an der Formulierung als an dem Inhalt. Ich würde es eher wie folgt sagen:

Code kann unabhängig von der Programmiersprache weitgehend objektorientiert aufgebaut sein. Abhängig von der Programmiersprache kann es aber unterschiedlich gut direkt unterstützt werden. Wenn Sprachen es nicht direkt unterstützen kann es aber sein das ein Teil der Sprachparadigmen nur umständlich oder durch Programmierdisziplin eingehalten werden kann.

Ich nehme mal die insgesamt 4 Begriffe aus der Stelle die ich zitiert habe und der Stelle die minhen zitiert hat:

Abstraktion
Vererbung
Polymorphie
Datenkapselung

rüdiger schrieb:

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

Damit ich eine Sprache Objektorientiert nenne, muss sie die Prinzipien auf möglichst direkte Weise umsetzen, sprich: möglichst ein Sprachfeature sein. Andernfalls kann man vielleicht sagen das die Sprache eine OO-Erweiterung hat, sie selbst ist aber nicht OO.

rüdiger schrieb:

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

Das kommt darauf an wie weit die Sprache OO als optionales oder als erzwingendes Feature einsetzt. Ja, man kann auch einen Backstein zu anderen Dingen missbrauchen als damit ein Haus zu bauen, ebenso wie man selbst dann, wenn eine Sprache OO zu erzwingen versucht, nicht zwangsweise OO-Programmiert. Es ist nur deutlich leichter.

Und ja, auch ich denke wenn ich OOP höre nicht als erstes an C++. C++ ist nicht rein OO, eher würde ich schon an sowas wie C# denken, was zumindest schon mehr OO zu erzwingen versucht.

Nur habe ich Schwierigkeiten mir z.B. ein C-Programm objektorientiert vorzustellen. Wo kann man dort bitte schön orientiert an einem Objekt programmieren und gleichzeitig die vier oben genannten Punkte erfüllen.
Ja, gehen tut das vielleicht, aber in Teilen nur dann, wenn der Programmierer bestimmte Dinge explizit berücksichtigt, die er bei anderen Sprachen direkt umsetzen kann (Datenkapselung nur als kleines Beispiel). Ein Objekt soll seine interen Statis nach außen verbergen können.

So um jetzt wieder auf das Thema zurückzukehren: Durch eine Objektorientierte Stuktur hat man IMHO in kleinen Projekten immer einen Performancenachteil, die Frage ist aber ob in der Gesamtheit die Strukturierung nicht mehr ausmacht.

Vom Prinzip ist C++ so geplant das es nur minimal langsamer als C ist (10%) und als das Exceptionhandling dazukam wurde hier auch nochmal ein Performancemalus eingeplant (weitere 10%). Ich glaube die Zahlen habe ich noch als Erinnerung aus dem Buch "Die C++ Programmiersprache". Was man natürlich berücksichtigen muss ist, das ein OO-Programm DURCH die OO-Paradigmen in der Regel nochmal etwas langsammer wird. Jetzt aber die Frage: Wenn ein Programm komplexer wird und schwerer zu überschauen ist, kann dann die C-Programmierung tatsächlich immer punkten oder kann hier die OO-Programmierung ggf. sogar Vorteile ausspielen.

Ja, wenn man beide optimiert ist das C-Programm wohl wieder schneller, ich sehe hier aber auch immer noch einen weiteren Faktor: Aufwand. In der Praxis ist meines Erachtens immer eine Balance zwischen den Extremen sinnvoll (Ausnahmen gibt es, z.B. Embedded Systems, Realtime Programming...).

cu André

rüdiger

asc schrieb:

Wenn Sprachen es nicht direkt unterstützen kann es aber sein das ein Teil der Sprachparadigmen nur umständlich oder durch Programmierdisziplin eingehalten werden kann.

"Disziplin"? Wenn ich dich richtig verstehe, braucht man das auch bei Sprachen, die OOP gut unterstützen. Man kann ja mit jeder Programmiersprache nicht OO-Code schreiben.

Damit ich eine Sprache Objektorientiert nenne, muss sie die Prinzipien auf möglichst direkte Weise umsetzen, sprich: möglichst ein Sprachfeature sein. Andernfalls kann man vielleicht sagen das die Sprache eine OO-Erweiterung hat, sie selbst ist aber nicht OO.

Warum "Erweiterung"? Die Möglichkeit ist doch in der Sprache vorhanden.

Das kommt darauf an wie weit die Sprache OO als optionales oder als erzwingendes Feature einsetzt. Ja, man kann auch einen Backstein zu anderen Dingen missbrauchen als damit ein Haus zu bauen, ebenso wie man selbst dann, wenn eine Sprache OO zu erzwingen versucht, nicht zwangsweise OO-Programmiert. Es ist nur deutlich leichter.

Also hilft die Sprache einem beim OOP?

Und ja, auch ich denke wenn ich OOP höre nicht als erstes an C++. C++ ist nicht rein OO, eher würde ich schon an sowas wie C# denken, was zumindest schon mehr OO zu erzwingen versucht.

Bei OOP denke ich eher an Ruby oder Smalltalk

Nur habe ich Schwierigkeiten mir z.B. ein C-Programm objektorientiert vorzustellen. Wo kann man dort bitte schön orientiert an einem Objekt programmieren und gleichzeitig die vier oben genannten Punkte erfüllen.
Ja, gehen tut das vielleicht, aber in Teilen nur dann, wenn der Programmierer bestimmte Dinge explizit berücksichtigt, die er bei anderen Sprachen direkt umsetzen kann (Datenkapselung nur als kleines Beispiel). Ein Objekt soll seine interen Statis nach außen verbergen können.

Gerade in C kann man das alles wunderbar emulieren. Vor ein paar Monaten habe ich mal in einer ähnlichen Diskussion ein C-Programm geschrieben, das sowohl Vererbung, Datenkapselung, Polymorphie und Abstraktion benutzte. Schau dir auch mal Objective C an. Das ist ja nur ein Preprozessor. Der spuckt einem ja OO-C-Code aus.

So um jetzt wieder auf das Thema zurückzukehren

Ich glaube nicht das OOP allgemein einen Performance-Nachteil hat. Die bereits angesprochenen "Kosten" von virtuellen-Funktionen hat man ja auch auf irgend eine Art und Weise, wenn man sie mit anderen Mitteln nachstellt. Nicht-Virtuelle Vererbung und Objekte kosten ja (in C++) nichts. Aber virtuelle-Vererbung ist in C++ ja ohnehin out.

hustbaer

@Xin:
Ich möchte hier genau auf eines antworten, nämlich hierraus (sonst wird mir das zu langwierig):

Xin schrieb:

Benutzt man kein virtual, wird die Nachricht nicht an das Objekt geschickt, sondern an die Klasse, die auf das Objekt zeigt.

Wo ist der Unterschied ob ich an einer bestimmten Stelle in einem Programm eine Nachricht an ein Objekt schickt oder "an seine Klasse", wenn die Klasse an der Stelle garantiert genau bekannt ist?

Einen Unterschied kann es IMO nur dann geben wenn man ganz auf Klassen verzichtet (denn dann KANN die Klasse des Objektes ja nicht bekannt sein, da es sie ja garnicht gibt). Das hat zugegebenermassen einige Vorteile, u.A. kann man dann quasi genau das was man braucht "dynamisch zusammenbasteln", aber ich kenne eigentlich niemanden von dem ich wüsste dass er den Begriff "OOP" so auslegt.

minhen

Mr. N schrieb:

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Schön, dass du den ganzen Thread gelesen hast.

Freut mich, dass du es schön findest.

loks schrieb:

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.

Das ist doch lächerlich. Du hast den verlinkten Text doch überhaupt nicht gelesen sondern nur das, was ich unten zitiert hatte. Und das stammte nicht aus dem verlinkten Text sondern aus einem Paper, welches dort angegeben ist. Was dagegen im verlinkten Text steht ist:

That said, object-oriented programming is a style of programming (...) relying of encapsulation, inheritance, and polymorphism. In the context of C++ (...), it means programming using class hierarchies and virtual functions (...)

Im verlinkten FAQ-Eintrag redet er also vom Programmieren - OOP - und nicht von Spracheigenschaften.

Wenn du meinst etwas kommentieren zu müssen, speziell wenn du dir einbildest widersprechen zu müssen, ist es wohl wirklich das Mindeste den Kram auch durchgelesen zu haben.

Jester schrieb:

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 hat eine präzise Definition vorgebracht und diese schlüssig begründet. Seine Definition ist minimal und damit sehr aussagekräftig. Damit erfüllt sie bereits eines der wichtigsten Brauchbarkeits-Kriterien. Das können andere Vorschläge hier bereits nicht mehr von sich behaupten. Die Schwammigkeit der anderen Vorschläge ist sogar deren Verfechtern hier, wie sie sogar selbst sagen, völlig klar. Schwammigkeit aber ist mit großem Abstand mit das Schlimmste, was einer Definition überhaupt passieren kann. Insofern ist Xins Definition diesen bereits von einem rein formalen Standpunkt aus überlegen.
Dazu kommt, dass er darlegt was ein Objekt ist und weshalb es in seiner Definition der zentrale Bestandteil ist, was wiederum die Begründung für den Begriff objekt-orientiert liefert. Dadurch ist die Definition nicht nur formal brauchbar sondern auch inhaltlich schlüssig (ohne schwammig zu werden) und dadurch überzeugend.
Xins Kritik an anderen Definitionen basiert ebenfalls auf den positiven Aspekten seiner eigenen Definition. So sind seine Angriffspunkte immer mangelnde Präzision (also Schwammigkeit) und mangelnde Aussagekraft (praktisch alles wäre OO).
Eine überzeugende Argumentation eben. Das wird vielleicht deutlicher wenn man sich die Angriffe der Gegenseite ansieht. Denn diese basieren dann doch zu einem großen Teil auf "Ich sage XYZ ist objektorientiert und das wäre es mit deiner Definition nicht. Folglich ist deine Definition schlecht." Ich hoffe es ist sofort einsichtig, warum Argumentationen die sich auf ein derartiges Schema bringen lassen, wenig überzeugend wirken. Die von dir angeführten "Standard-Referenzen" wiederum verleihen zwar Gewicht - machen aber nicht überzeugender. Oder warum gibst du dich nach dem Verweis auf eine Größe wie Bjarne Stroustrup nicht geschlagen? Eben. Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

rüdiger schrieb:

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

Auf die Sprachen selbst bezogen sagt er dazu im Paper:

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.

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte (Kapselung, Vererbung, Laufzeit-Polymorphie) direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind. Man muss sie sich also nicht selbst bauen. Direkt kann nur bedeuten, dass diese Hilfsmittel unmittelbarer Bestandteil der Sprache sein müssen. Folglich macht weder die Möglichkeit Objekt-Orientierung selbst zu bauen noch eine externe, objektorientierte Library eine Sprache objektorientiert.

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

Dazu sagt Stroustrup im verlinkten Paper, dass eine objekt-orientierte Sprache OOP einfacher und effizienter nutzbar macht. Und diese Vorteile von OOP beschreibt er in der FAQ wie folgt:

... to allow manipulation of objects of a variety of types through well-defined interfaces and to allow a program to be extended incrementally through derivation.

Der Vorteil von OOP ist es also verschiedene Objekte mit definierten Schnittstellen ansprechen zu können, sowie die Möglichkeit Programme bequem inkrementell erweitern zu können. Wichtig ist, dass hier kein Wort davon fällt, bestehenden Code ändern zu müssen. Damit ist auch klar weshalb Polymorphie ein unentbehrlicher Bestandteil von OOP ist.

Nebenbei verweist er auch darauf, dass manchmal u.a. auch im objekt-orientierten C++ Programmierung mit "plain classes" für ein Problem besser ist. Das, sowieo was er sonst noch so sagt, legt nahe, dass er der vernünftigen Auffassung ist, dass die Verwendung einer objekt-orientierten Programmiersprache noch lange nicht per se objekt-orientierte Programmierung bedeutet.

otze

Dazu kommt, dass er darlegt was ein Objekt ist und weshalb es in seiner Definition der zentrale Bestandteil ist, was wiederum die Begründung für den Begriff objekt-orientiert liefert. Dadurch ist die Definition nicht nur formal brauchbar sondern auch inhaltlich schlüssig (ohne schwammig zu werden) und dadurch überzeugend.
Xins Kritik an anderen Definitionen basiert ebenfalls auf den positiven Aspekten seiner eigenen Definition. So sind seine Angriffspunkte immer mangelnde Präzision (also Schwammigkeit) und mangelnde Aussagekraft (praktisch alles wäre OO).

Nun musst du aber auch anerkennen, dass die Gegenseite ausserhalb dem Verweis auf Standarddefinition einen schlechten Stand hat. Unsere Definition ist die eines Objektes aus dem normalen Sprachgebrauch und das Übertragen dieser Objekte und ihren abhängigkeiten auf die Ebene des Programmcodes ist nunmal nicht formal eindeutig definierbar. Das fängt schon damit an, dass der Begriff "Objekt" im allgemeinen Sprachgebrauch nicht eindeutig definiert ist:

de.wikipedia.org/wiki/Objekt

Objekt bezeichnet:* allgemein etwas unspezifiziertes, siehe Sache, Gegenstand, Ding* im Sinne der Dialektik das, worauf ein Subjekt seine beobachtende, sinnliche, empirische und praktisch-verändernde Aktivität richtet

Brockhaus:

allg: Gegenstand, mit dem etwas geschieht oder geschehen soll

Philosophie:[...] In der modernen Sprachphilosophie und in der Logik wird all das als Objekt genannt, was sprachlich unterschieden werden kann

Im Sinne dieser Objekt definition zählt nur das denken in Objekten und das Übertragen dieser Denkweise in den Code. Das bedeutet aber nicht, dass jeder Code direkt OOP ist, denn es besteht einen unterschied zwischen: "Objekt a ruft methode foo von Objekt b auf" und "erst wird foo aufgerufen, dann bar und wenn x=5 gilt dann wird noch fubar aufgerufen". Wie das am Ende im Code umgesetzt wird, ist absolut Sprachabhängig. kennt die Sprache keine methoden, dann müssen normale Funktionen dafür herhalten(bei File:"Ich öffne das DateiObjekt mit open").

Ich hoffe, nun wurde klar, wieso Xins argumentation für mathematiker/logiker besser wirken muss, seine Definition hat die Problemstellung so eingeschränkt, dass der letzte gültige Teilaspekt, oh wunder, eindeutig definierbar ist.
Und der Gegenseite bleibt nur zu sagen: Dies schließt aber extrem viele Fälle aus. Nur, wie soll man weiter gegen irgendwas argumentieren was teil der eigenen definition ist? es ist nunmal nicht wegdiskutieren, dass Polymorphie ein Teil der OOP ist. Uns bleibt nur, rein wissenschaftlich argumentativ, die Fälle aufzuzeigen, die nach unserer Definition OOP sind(völlig begründet, aber darauf geht Xin nicht ein, auch typisch wissenschaftlich), aber von Xins Definition nicht eingeschlossen werden. Solange er aber auf diese Fälle nicht eingeht, zb warum statische Polymorphie kein OOP ist, können wir auch nicht weiter argumentieren.

btw: zum von .filmor geposteten link. Also wenn das der Code ist, mit dem du getestet hast, dann wundert mich das nicht wirklich.
1. im C-Code wird ne hash-map genutzt, im C++ Code ein RB-Baum. Also am Ende O(1) vs O(log N)
2. sprintf vs C++ streams. Da sind die streams deutlich langsamer, weil sie eine andere Philosophie haben. Damit sind die beiden Sachen kein analogon.
3. Die Deque im C++ teil kommt mir Spanisch vor, muss aber auch gestehen, dass ich bei diesen Variablennamen und der nicht vorhandenen Dokumentation nicht 100% genau verstehe, was der author da vor hat zu machen, zumal der testlauf des C++ Codes nur wieder das ausgegeben hat, was ich zuerst eingegeben habe.

Xin legt einfach willkürlich fest, daß es "der Algorithmus" zu sein habe, der "sich am Objekt" orientiert.
Übersetzt man OOP wörtlich, steht da aber als letztes "Programmierung", nicht "Algorithmus". Die ganze Programmierung muß sich also an Objekten orientieren. Und jetzt definier mal, was "sich an etwas orientieren" exakt bedeutet, darauf bin ich sehr gespannt.

Uiuiui, hab grade den Fehler gemacht, den von otze genannten Thread mal durchzulesen. Au Backe...

Auf Schreibfehlern anderer herumreiten, wo man doch selbst auf seiner HP und in seinen Beiträgen am laufenden Band Patzer reinbaut
Ständig nebenbei alle anderen abqualifizieren
Ständig das Böse aller anderen vorwegnehmen (-> Arroganz?)
"Weder Datenkapselung noch Klassen sind für OOP nicht erforderlich. Schau Dir mal die Implementierung von "virtual" und überlege Dir, warum OOP nicht "datengekapselte-Programming" oder "klassenbasierte Programming" oder "Datenvererbende Programming" heißt." Schwammiger kann man sich nicht ausdrücken, oder?

Mein Gott, Walter.

asc

minhen schrieb:

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte ... direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind... Direkt kann nur bedeuten, dass diese Hilfsmittel unmittelbarer Bestandteil der Sprache sein müssen. Folglich macht weder die Möglichkeit Objekt-Orientierung selbst zu bauen noch eine externe, objektorientierte Library eine Sprache objektorientiert.

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

cu André

Simon2

Undertaker schrieb:

asc schrieb:

Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."

http://www.iam.unibe.ch/~denker/old/AlanKayQuotes.html
5te zeile

Die 3. steht aber noch davor und ist aber auch schön, oder ?

Undertaker

Simon2 schrieb:

Undertaker schrieb:

asc schrieb:

Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."

http://www.iam.unibe.ch/~denker/old/AlanKayQuotes.html
5te zeile

Die 3. steht aber noch davor und ist aber auch schön, oder ?

grrrr.....

TheTester

asc schrieb:

minhen schrieb:

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte ... direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind... Direkt kann nur bedeuten, dass diese Hilfsmittel unmittelbarer Bestandteil der Sprache sein müssen. Folglich macht weder die Möglichkeit Objekt-Orientierung selbst zu bauen noch eine externe, objektorientierte Library eine Sprache objektorientiert.

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

cu André

Eben nicht, minhen unterscheidet zwischen dem Konzept der OOP und einer objekt-orientierten Sprache. Das Konezpt der OOP ist unabhängig von der Sprache, eine Sprache jedoch wird zur OOP Sprache wenn sie das Konzept der OOP auf irgendeine Art direkt implementiert. Das heisst jedoch nicht das man nicht in einer Nicht-OOP Sprache nicht auch OOP Konzepte verwenden kann, die Sprache unterstützt dich hierbei nur nicht.

tt

asc

TheTester schrieb:

Eben nicht, minhen unterscheidet zwischen dem Konzept der OOP und einer objekt-orientierten Sprache. Das Konezpt der OOP ist unabhängig von der Sprache, eine Sprache jedoch wird zur OOP Sprache wenn sie das Konzept der OOP auf irgendeine Art direkt implementiert. Das heisst jedoch nicht das man nicht in einer Nicht-OOP Sprache nicht auch OOP Konzepte verwenden kann, die Sprache unterstützt dich hierbei nur nicht.

Ich wiederspreche dem nicht, aber in der Konstellation wie er (minhen) es geschrieben hat, hätte ich nicht seinen logischen Schluß ziehen können.

cu André

Jester

minhen schrieb:

Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

Das ist schlicht nicht wahr. Aber das kann ja jeder selbst nachlesen.

Ich weiß auch nicht was Dich an der Definition so begeistert. Klar okay, sie ist einfach. Ich würde sagen, sie ist sogar so stupide trivial, dass sie sich für garnichts eignet. Das ist natürlich prima und eine wichtige Voraussetzung für eine gute Defintion.

Aber was bringt mir diese Definition? Es geht doch darum eine ganze Menge von Techniken zu einer gemeinsamen Methodik zusammenzufassen. "Wenn virtual benutzt wird isses OOP, sonst nicht" ist zwar prima, wenn ich algorithmisch entscheiden möchte, ob ein gegebener Source OO ist. Aber das ist eigentlich nicht das was man sich von dieser Definition erhofft.

Abgesehen davon, dass er sich ja nicht am Objekt, sondern am Typen des Objekts orientiert. Müßte es da nicht streng genommen OTOP also Objekt-Typ orientierte Programmierung heißen?

Ich verrat's jetzt einfach mal: OOP heißt Objekt-orientierte Programmierung, weil man sich an Objekten orientiert: Sie stellen die zentrale Abstraktionsmöglichkeit bereit, Systeme werden dadurch beschrieben, welche Objekte es gibt, welches Verhalten diese modellieren und wie diese miteinander interagieren. Objekte tauchen gleichermaßen in der Modellierung wie in der Implementierung auf. Und weil sie eben bei dieser Methode so häufig vorkommen und so zentral sind heißt sie Objektorientiert.

Helium

Xin schrieb:

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.

Multimethoden dispatchen auch erst zur Laufzeit, da dort auch erst zur Laufzeit die Typ-Information vorhanden ist und nicht zur Compilezeit. Darum geht es doch gerade bei Multimethoden.

Beispiel:

(defmethod collide-with ((x asteroid) (y asteroid))
  ;; deal with asteroid hitting asteroid
)
(defmethod collide-with ((x asteroid) (y spaceship))
  ;; deal with asteroid hitting spaceship
)
(defmethod collide-with ((x spaceship) (y asteroid))
  ;; deal with spaceship hitting asteroid
)
(defmethod collide-with ((x spaceship) (y spaceship))
  ;; deal with spaceship hitting spaceship
)

Zur Compile-Zeit habe ich keine Typinformationen. Erst zur Laufzeit kann entschieden werden, welche der Methoden denn jetzt aufgerufen werden kann und zwar wird anhand beider Argumente dispatched.

Xin

Okay, hier sind Antworten für alle in einem Posting.

Jester schrieb:

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.

Nein, ich frage, warum Objekte, die nicht über virtuelle Klassen verfügen, also von statisch bearbeitet, "objekt orientiert" genannt werden, obwohl sich kein Algorithmus am Objekt orientiert.

.filmor schrieb:

Jester schrieb:

Ich bestreite den Faktor 5-10. Her mit den Sourcen, dann schaun wir weiter.

Das hier höchstvermutlich.

Treffer.

asc schrieb:

Ich würde garnicht erst versuchen mit Xin zu diskutieren, ich habe das einmal erlebt. Er hat seine Meinung und nur die gilt.

Das hier möchte ich gerne kommentieren, denn das wird mir häufig nachgesagt.
Es ist problemlos möglich, meine Meinung zu kippen, ich beschrieb ja auch schon, dass man nur eine Frage sinnvoll beantworten muss, um das zu erreichen.
Der Punkt ist, dass ich mich damit seit ein paar Jahren beschäftige und in diesem Thread noch nichts gelesen habe, meine in meiner Meinung nicht berücksichtig ist. Alles auf diesen Seiten ist mir bekannt und damit auch Grund, warum ich eine andere Meinung vertrete als die Mehrzahl hier.
Wäre ich mir mit meiner Meinung nicht so sicher, würde ich in meine Aussagen Relativierungen einbauen wie "Ich finde..." oder "Meiner Meinung nach...", um zu kennzeichnen, dass ich auch andere Ansichten akzeptiere.
Ich heuchle auch keine Fachkompetenz, um etwas zu schreiben. Wenn ich keine Ahnung habe - zum Beispiel in diesem Thread von LISP - sage ich das und lasse mich nicht auf eine Diskussion ein. Wenn ich diskutiere, bin ich mir sehr sicher, den richtigen Standpunkt zu vertreten, weil ich ihn auf alle Eventualitäten abgeklopft habe, die mir eingefallen sind.
Hierbei handelt es sich um eine Definition, eine Vokabel der Informatik. Hier akzeptiere ich nur eine Ansicht und wie minhen später gut zusammenfasst, hat eine große schwammige Definition nicht den Wert um eine kleine aber scharfe Definition zu ersetzen.

asc schrieb:

Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."
Wofür Xin aber wiederum durchaus nützlich ist, ist für Lektürenreferenzen. Ich kann zwar bislang keiner seiner Textinterpretationen zustimmen, aber Interessantes und Neues gibt es dort immer zu finden. Und als Leseratte lehne ich nie Lektüretips nie ab.

Vollkommen richtig. Und vermutlich meint er damit "plain classes", die er abseits dazu aufführt und vermutlich nimmt er grade deswegen ein Beispiel, dass die Verwendung von virtual aufzeigt, um OOP vorzuführen.
Ich weiß nicht, wie Du oder der Rest Texte interpretiert, aber derzeit hört sich das so an, als würde man interpretieren mit ignorieren verwechseln. ^^

michba schrieb:

hui schrieb:

Jester schrieb:

...sei doch ruhig wenn sich Diplominformatiker über Dinge unterhalten ...

Arroganz++

Obwohl es wahrscheinlich sowieso nichts bringt, darauf zu antworten: das ist für mich keine Arroganz von Jester, sondern nur die berechtigte Reaktion auf DEvents Arroganz:

DEvent ist nicht arrogant, sondern Unwissend. Statt zu erläutern darauf rumzureiten ist für mich (Relativierung - siehe oben) arrogant. Von daher erscheint mir DEvent hier eine korrekte Antwort auf Jesters Äußerung gegeben zu haben. Ich habe Jesters Aussage da als massiv unhöflich gegenüber DEvent empfunden.

hustbaer schrieb:

@Xin:
Ich möchte hier genau auf eines antworten, nämlich hierraus (sonst wird mir das zu langwierig):

Xin schrieb:

Benutzt man kein virtual, wird die Nachricht nicht an das Objekt geschickt, sondern an die Klasse, die auf das Objekt zeigt.

Wo ist der Unterschied ob ich an einer bestimmten Stelle in einem Programm eine Nachricht an ein Objekt schickt oder "an seine Klasse", wenn die Klasse an der Stelle garantiert genau bekannt ist?

Schau Dir diesen Code an, der nicht objektorientiert arbeitet:

#include <iostream>

class Tier 
{ 
  public: 
    void GibLaut() { std::cout << "Hallo!"; }   // Hier fehlt virtual, um objektorientierung zu verwenden
}; 

class Katze : public Tier 
{ 
  public: 
    void GibLaut() { std::cout << "Miau"; } 
};

int main( void )
{
  class Tier * tier  = new Katze(); 
  tier->GibLaut();  
}

hustbaer schrieb:

Einen Unterschied kann es IMO nur dann geben wenn man ganz auf Klassen verzichtet (denn dann KANN die Klasse des Objektes ja nicht bekannt sein, da es sie ja garnicht gibt).

Man kann für OOP problemlos auf Klassen verzichten, allerdings verzichtet man dann auch auf die Unterstützung zu OOP von C++, da sich virtual nunmal auf Klassen bezieht.

minhen schrieb:

[...] Xin hat eine präzise Definition vorgebracht und diese schlüssig begründet. Seine Definition ist minimal und damit sehr aussagekräftig. Damit erfüllt sie bereits eines der wichtigsten Brauchbarkeits-Kriterien. [...]

Dein Posting fasst sehr gut meine (wiederholten) Aussagen der letzten 12 oder mehr Seiten zusammen. Ich freue mich, dass sie wenigstens einer gelesen und verstanden hat. Das erscheint mir mit jeder weiteren Seite dieses Threads als etwas besonderes.
Ebenfalls freut mich, dass Du Dich dem Pulk hier freiwillig entgegenstellst und sie damit ebenfalls anregst, ihre Definitionen zu verschärfen.

scrub_ schrieb:

Xin legt einfach willkürlich fest, daß es "der Algorithmus" zu sein habe, der "sich am Objekt" orientiert.
Übersetzt man OOP wörtlich, steht da aber als letztes "Programmierung", nicht "Algorithmus".

Programmierung bedeutet Algorithmen zu formulieren. Man programmiert, damit sich Algorithmen um Daten (==Objekte) kümmern.

Und eine Wiederholung dazu, da das ganze schon erklärt wurde: Würde man OOP daran ausrichten, dass sich der Programmierer an Objekten orientiert, ist absolut alles objektorientiert, was mit Objekten ("irgendein Ding", z.B. char, int, double..., aber eben nicht void) arbeitet. Dazu gehören Assembler, C, Bash-Programmierung, usw.
Eine OOP-Unterstützung der Frage ist, ist wenn sich der Programmierer an Daten orientiert, in definitiv allen Sprachen gegeben.

Darum ist meine Festlegung nicht willkürlich, sondern zielgerichtet.

asc schrieb:

minhen schrieb:

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

Falsch, es gibt keine OO-Sprachen, es gibt Sprachen, die OO unterstützen (z.B. C++) und es gibt Sprachen, die OO fordern (z.B. Java) und es gibt Sprachen, die das OO nicht unterstützen (z.B. C).
Und in allen Sprachen kann man strukturiert, wie auch objektorientiert programmieren.

Jester bekommt mehr Antworten, weil er die grundlegensten Fragen stellt:

Jester schrieb:

minhen schrieb:

Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

Ich weiß auch nicht was Dich an der Definition so begeistert. Klar okay, sie ist einfach. Ich würde sagen, sie ist sogar so stupide trivial, dass sie sich für garnichts eignet. Das ist natürlich prima und eine wichtige Voraussetzung für eine gute Defintion.

Nicht stupide, eindeutig. Sie trennt OOP von anderen Techniken, wie Klassen ("plain classes") oder Templates.

Jester schrieb:

Aber was bringt mir diese Definition? Es geht doch darum eine ganze Menge von Techniken zu einer gemeinsamen Methodik zusammenzufassen.

Im Gegenteil, es geht darum, Techniken auseinander zu halten und exakt benennen zu können. Wenn Du Techniken zusammenfassen möchtest, kannst Du sagen "in C++ Techniken". Das beinhaltet OOP, "plain classes", DataHiding, RTTI, Templates und vieles mehr.

Jester schrieb:

"Wenn virtual benutzt wird isses OOP, sonst nicht" ist zwar prima, wenn ich algorithmisch entscheiden möchte, ob ein gegebener Source OO ist. Aber das ist eigentlich nicht das was man sich von dieser Definition erhofft.

Ich weiß nicht, was Du Dir von einer Definition erhoffst. Ihr sagt selbst, dass eure Definition schwammig ist, also bringt sie nichts. In einem anderen Posting hier beginnt die Diskussion mit "Du musst mir erst noch erklären, was Du unter eine OOP-Sprache verstehst...". Das ist doch keine Definition, das ein einzig großes Mißverständnis.

OOP ist nicht willkürlich definiert, man kann damit sagen, ob ein Programm OOP verwendet oder nicht. Genauso kannst Du sagen, ob Listen oder Arrays verwendet werden. Würde man das ebenso schwammig definieren, wären Arrays auch Listen, weil in beiden Fällen werden mehrere Objekte gespeichert.

Nach eurer Definition sind Arrays eine objektorientierte Technik, weil der Programmierer sich an Objekten orientiert, wenn der Arrays erzeugt, die Objekte speichern. Die Definition von OOP macht doch keinen Sinn, wenn sie so schwammig ist, dass man alles in sie hineininterpretieren kann.

Jester schrieb:

Abgesehen davon, dass er sich ja nicht am Objekt, sondern am Typen des Objekts orientiert. Müßte es da nicht streng genommen OTOP also Objekt-Typ orientierte Programmierung heißen?

Ich halte das tatsächlich für eine sinnvolle Verbesserung und werde das zur Verdeutlichung benutzen, um die Bedeutung von OOP zu erklären.

Xin

Helium schrieb:

Xin schrieb:

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.

Multimethoden dispatchen auch erst zur Laufzeit, da dort auch erst zur Laufzeit die Typ-Information vorhanden ist und nicht zur Compilezeit. Darum geht es doch gerade bei Multimethoden.

Korrekt. Aber das ist doch nur bedingt objektorientiert, da die möglichen Objekttypen zur Compilezeit bekannt sein müsen.
Diese Technik hat man mit virtuellen Funktionen (Edit: "OOP" entfernt) ja eben entfernen wollen, schließlich wurden so in C die Fehler produziert.

Helium schrieb:

(defmethod collide-with ((x asteroid) (y asteroid))
  ;; deal with asteroid hitting asteroid
)
(defmethod collide-with ((x asteroid) (y spaceship))
  ;; deal with asteroid hitting spaceship
)
(defmethod collide-with ((x spaceship) (y asteroid))
  ;; deal with spaceship hitting asteroid
)
(defmethod collide-with ((x spaceship) (y spaceship))
  ;; deal with spaceship hitting spaceship
)

entspricht:

void collide_with( SpielObjekt & lhs, SpielObjekt & rhs )
{
  if( typeid( lhs ) == typeid( asteroid ) && typeid( rhs ) == typeid( asteroid )
    ;; deal with asteroid hitting asteroid

  if( typeid( lhs ) == typeid( asteroid ) && typeid( rhs ) == typeid( spaceship )
    ;; deal with asteroid hitting spaceship

  if( typeid( lhs ) == typeid( spaceship ) && typeid( rhs ) == typeid( asteroid )
    ;; deal with spaceship hitting asteroid

  if( typeid( lhs ) == typeid( spaceship ) && typeid( rhs ) == typeid( spaceship )
    ;; deal with spaceship hitting spaceship
}

Sobald man Raketen hinzufügt, muss collide_with verändert werden und collide-with kann auch nicht mehr auflösen.
Löst man das ganze mit OOP, also virtuellen Funktionen auf, ergibt sich an collide_with keine Änderung.

Erkennst Du nun den Unterschied?

EDIT: Ich möchte noch hinzufügen, dass Multimethoden sich natürlich am Objekt orientieren => sie sind objekt orientiert. Sie stellen allerdings eine begrenzte Technik dar, die - weil die Typen zur Compilezeit bekannt sein müssen. Sie ist also davon abhängig, dass die Anzahl der möglichen Typen sich nicht verändert.
In einer Library sind sie nicht verwendbar.

Über eine virtuelle Funktion lässt sich eine das ganze Problem besser lösen:

void collide_with( SpielObjekt & lhs, SpielObjekt & rhs )
{
  lhs.collide_width( rhs );
}

Asteriod kann mit Asteriod kollidieren. Kollidiert er mit etwas anderem, lässt er sich mit dem anderen kollidieren.
Spaceship kann mit Asteriod und Spaceship kollidieren, sonst kollidiert es mit dem anderen.

Erweitert man das Programm nun mit Raketen, so beschreibt man in Rakete, wie eine Rakete mit Asteroiden, Spaceships und Raketen kollidiert. Ansonsten sind nirgendwo Änderungen im Code erforderlich, weil der Code sich vollkommen am Objekt orientieren kann, ohne vom Typ des Objektes abhängig zu sein.

Einfache OOP-Techniken, wie diese, haben in C viele Fehler verursacht, weil an einzelnen Stellen vergessen wurde, den Code zu erweitern.

otze

Xin schrieb:

Sobald man Raketen hinzufügt, muss collide_with verändert werden und collide-with kann auch nicht mehr auflösen.
Löst man das ganze mit OOP, also virtuellen Funktionen auf, ergibt sich an collide_with keine Änderung.

Erkennst Du nun den Unterschied?

falsch. Wenn du vererbung verwendest, musst du jede Klasse verändern, wenn du Rakete hinzufügst. das ist double dispatching, und die OOP bietet dafür keine Lösung. Ausser natürlich, für die 3 Objekte reicht derselbe CollideWith algorithmus. Aber wenn man annimmt, dass Asteroid ein kreis, raumschiff ein quadrat und rocket ein Strich ist, dann brauchst du für jede kombination eine eigene methode. Und anstatt dann an einer Stelle einfach die neuen funktionen hinzuzufügen, musste es dann in jeder Klasse machen. dazu kommt, dass du dich ab dann noch damit rumschlagen kannst, dass in Raumschiff Rakete noch nicht definiert ist und du dann nochmal irgendwo ne vorwärtsdeklaration brauchst(in C++ natürlich). Ohja, nicht zu vergessen, dass du dann noch das Problem hast, dass jede Klasse erstmal rauskriegen muss, welchen genauen typ nun das übergebene objekt hat, damit dann die endgültige methode aufgerufen werden kann.

Das Ergebnis ist dann, dass du nichtmehr eine dispatch funktion hast, sondern für jede Klasse eine(nämlich singledispatch):

class Asteroid;
class SpaceShip;
Class Rocket:public Object
{
    public:
        virtual bool collide(const Object* o)const
        {
             if(typeid(o)==typeid(Asteroid))
             {
                  //collide with asteroid
             }
             if(typedid(o)==typeid(SpaceShip)
             {
                 //collide with SpaceShip
             }
             if(typedid(o)==typeid(Rocket)
             {
                 //collide with Rocket
             }
        }
};
//selbes für Asteroid und Spaceship
...

bool collideWith(const Object* o1,const Object* o2)
{
    return o1->collide(o2);
}

und wenn du jetzt einen Typ hinzufügst, kann keine dieser Dispatchfunktionen mehr auflösen, du musst also nicht nur die neuen Funktionen hinzufügen, nein du musst auch noch alle dispatchfunktionen anpassen(mit C++ und statischer Polymorphie ist das übrigens nur ein ",Typename" in der Typliste, dann ist der komplette doubleDispatcher wieder up to date ;)).

Erkennst du den unterschied?

Aber wozu mach ich mir die Mühe? mir antwortest du ja eh net

asc

Xin schrieb:

asc schrieb:

Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."
Wofür Xin aber wiederum durchaus nützlich ist, ist für Lektürenreferenzen. Ich kann zwar bislang keiner seiner Textinterpretationen zustimmen, aber Interessantes und Neues gibt es dort immer zu finden. Und als Leseratte lehne ich nie Lektüretips nie ab.

Vollkommen richtig. Und vermutlich meint er damit "plain classes", die er abseits dazu aufführt und vermutlich nimmt er grade deswegen ein Beispiel, dass die Verwendung von virtual aufzeigt, um OOP vorzuführen.
Ich weiß nicht, wie Du oder der Rest Texte interpretiert, aber derzeit hört sich das so an, als würde man interpretieren mit ignorieren verwechseln. ^^

Stimmt, du ignorierst auch alle Sätze die Bjarne Stroustrup zwischen dem Kommentierten und den Beispiel schreibt, ebenso wie ein Teil des Kommentars als solchen (z.B. encapsulation, inheritance), wenn du OO nur und ausschließlich auf virtuell begründest.

In the context of C++ (and many other languages with their roots in Simula), it means programming using class hierarchies and virtual functions to allow manipulation of objects of a variety of types through well-defined interfaces and to allow a program to be extended incrementally through derivation...

Aber im Zweifel kann jeder den bereits geposteten Link folgen und seine eigenen Interpretationen von Bjarne Stroustrup's Ansichten machen (hier nochmal: http://www.research.att.com/~bs/bs_faq.html#oop).

Mir ist ehrlich gesagt egal wie du die Begriffe Interpretation und Ignorieren verwendest, für meine Interpretation versuche ich jedenfalls möglichst den Gesamtkontekt heranzuziehen und nicht alles das was mir nicht passt zu Ingorieren. Ich habe in meinen Leben mich schon ab und zu eines besseren belehren lassen, aber ich bezweifel das du andere Ansichten auch nur in Betracht ziehst. Mir fällt da nur "Was nicht passt wird passend gemacht" oder "Brecheisenmentalität" ein.

cu André