Performancemythen?
-
minhen schrieb:
"Ja", aber mit Laufzeit-Polymorphie. Und das ist etwas was du offensichtlich nicht verstehst. Virtuelle Funktionen sind die Methode um Laufzeit-Polymorphie in C++ zu implementieren.
Sind _eine_ Methode um Laufzeit Polymorphie in C++ zu implementieren und eine seltene Methode um Polymorphie in C++ zu implementieren (Templates verwendet man für Polymorphie in C++ öfter als virtual).
Du bist aber offenbar so tief in der C++-Gedankenwelt verwurzelt, dass dir die Gemeinsamkeiten überhaupt nicht auffallen.
Eben nicht. Ich rede nicht von C++, ich rede meistens von JavaScript, Self, Nice, Lisp,...
Laufzeit-Polymorphie hast du sowohl in C++ als auch in C als auch in Perl als auch in JavaScript. Dass ist das Konzept, welches in C++ mit "virtual" verfügbar ist. Aber deswegen fehlt das Konzept noch lange nicht in anderen Sprachen, die nicht dieses Schlüsselwort verwenden.
Laut Xin ist aber der entsprechende JavaScript Code mit Laufzeit Polymorphie - ohne virtual aber - kein OO Code.
Und neben "Laufzeit Polymorphie" gibt es eben noch "statische Polymorphie" - wobei ich bereits mehrfach erklärt habe dass diese Begriffe nicht technisch zu verstehen sind - denn auch "statische Polymorphie" kann zur Laufzeit aufgelöst werden.
Dann geht es damit weiter wie man virtuelle Methoden in C implementieren kann. Lies das Kapitel mal. Schadet dir sicher nicht. Also befrei dich lieber mal von deiner eingeschränkten C++-Sicht. Andere Sprachen, andere Mittel, selbes Konzept.
Danke ich kann besser C als du
Aber virtuelle Funktionen in C sind auch nur _eine_ Möglichkeit laufzeit Polymorphie zu implementieren - ich habe in diesem Thread bereits eine andere Möglichkeit implementiert.
Aber gut, ich frage dann dich mal, ist folgender Code OOP?
function Dynamo() { this.get_energie = function(){} } function Atomreaktor() { this.get_energie = function(){} } function Lampe(energiequelle) { this.e=energiequelle } lampe=new Lampe(new Dynamo())Laut Xin ist das nicht OOP. Ist es für dich OOP?
-
Shade Of Mine schrieb:
Danke ich kann besser C als du
den gleichen satz hast du schon mal gebracht, nur mit JavaScript.
-
Undertaker schrieb:
Shade Of Mine schrieb:
Danke ich kann besser C als du
den gleichen satz hast du schon mal gebracht, nur mit JavaScript.
Ich hasse es mir Leute statt über das Thema zu reden die Grundlagen von einer Sprache erklären wollen...
Was mich da aber interessiert, @minhen:
Wie gut kennst du dich mit Self, Nice, Lisp, Haskell, JavaScript,... aus?
-
Shade Of Mine schrieb:
Ich hasse es mir Leute statt über das Thema zu reden die Grundlagen von einer Sprache erklären wollen...
immer schön cool bleiben.
aussagen wie 'ich kann dieses und jenes besser als du' wirken nur kindisch.
-
Xin schrieb:
...
minhin schrieb:
Xin schrieb:
Mich hätte hier lediglich Marc++us Definition noch interessiert. Ich gehe nicht davon aus, dass er mir zustimmt, weil meine Definition braucht man nicht zu binden, da tun es auch ein, zwei Blätter. Ich gehe aber davon aus, dass wenn er schon ein Buch schreibt, er sich ebenfalls intensiver mit dem Thema beschäftigt hat und entsprechend schärfere Definitionen benutzt.
Marcus bezeichnet (Laufzeit-)Polymorphie in seinem Buch als "wesentliches Merkmal der objektorientierten Programmierung". Laufzeit-Polymorphie macht also das Wesen von OOP aus.
Was in C++ durch virtuelle Funktionen erreicht wird...
Aber das ist doch nur ein Mechanismus, mit welchem OOP in C++ ermoeglicht wird.
Das heisst nicht, dass das generell so sein muss.Ich habe den Eindruck, du faehrst dich hier auf einem Sprachfeature fest, bitte
korrigiere mich, wenn ich falsch liege.gruss
v R
-
Wenn ich jetzt ein einfaches Programm schreibe, bei dem es garkein switch/OOP Laufzeitpolymorphie benötigt wird, dann kann ich da garkeine OOP anwenden?
-
Vom sachlichen Endergebnis sin solche "Diskussionen" (im Grunde ist es ja eher ein "dädä, ich weiß es besser als du!11") total fürn Arsch. Aber für Psychologen wäre es bestimmt interessant.
-
minhen schrieb:
Shade Of Mine schrieb:
Aber ich kann nicht oft genug wiederholen: Es gibt massig Sprachen ohne virtuelle Funktionen. zB JavaScript.
"Ja", aber mit Laufzeit-Polymorphie. [...]
Warum muss es denn ausschließlich "Laufzeit-Polymorphie" sein? (was zB der Stroustrup gar nicht sagt, falls du mal wieder irgend was zitieren und entsprechend deiner Meinung auslegen willst)
-
otze schrieb:
Diese beziehung hab ich garnicht im UML diagramm dargestellt und bei der version mit abstraktet basisklasse gibts das auch nicht.
Was wolltest du nochmal trollen?
Jetzt bezeichnet ihr mich als Troll?
-----------------| |---------| | Klasse1 | | Klasse2 | |----------------| |---------| | Member |<----|.... | |----------------| |---------| |Klasse1(Member1)| | | |function() | |foo() | |________________| |---------| / \ / \ / \ |-----------| |-----------| |Konkret1 | |Konkret2 | |... | |... | |-----------| |-----------| |foo() | |foo() | |-----------| |-----------|In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Da schenke ich dem Thread paar Tage keine Beachtung, und schon werde ich als Troll denunziert.
Shade Of Mine schrieb:
Ich sehe da das Problem nicht. Warum ist es falsch zu sagen "alles was sich wie eine Energiequelle verhält, ist eine Energiequelle". Warum soll das falsch sein?
Kann sein das es manchmal nicht wichtig ist. Ein Vogel kann fliegen, ist er damit ein Flugzeug?
rüdiger schrieb:
Seit wann sind die von dir genannten Punkte Bestandteil einer Definition?
Wenn man diese einfachen Fragen nicht beatworten kann, ist eine Definition nutzlos.
Overtaker schrieb:
@DEvent: schau dir mal eine dynamisch typisierte sprache wie eben javascript oder so an dann sollte sich dein missverstehen zu shades posts wohl klären
Kein Missverstaendniss. Ich habe gesagt das diese BEziehung in JS nicht gegeben ist, Shader hat gesagt das es nicht wichtig seih.
-
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Und nu?
-
rüdiger schrieb:
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Und nu?
Otze und Shader haben gesagt das der JS und Template Code das gleiche ist, wie der C++ und der Java Code, ich stimmt mit ihnen nicht ueberein, weil man diese Beziehung in JS/Tpm gar nicht abbilden kann. Das wars.
-
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
ich hatte weiter oben ein tool erwähnt (rhapsody in C), das solche diagramme in C (eine sprache, die mit OOP nichts am hut hat), überführen kann.
warum sollt es dann nicht mit JS gehen?
-
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
-
merker schrieb:
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
was gibt es da zu diskutieren? C ist von haus aus nicht objektorientiert, im gegensatz zu etwa C#, Java, Smalltalk, Objective-C und was-weiss-ich. natürlich kann man mit C objektorientierung nachbilden, genau so wie man's z.b. mit assembler (und ich denke auch JS) machen kann.
-
Undertaker schrieb:
merker schrieb:
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
was gibt es da zu diskutieren? C ist von haus aus nicht objektorientiert, im gegensatz zu etwa C#, Java, Smalltalk, Objective-C und was-weiss-ich. natürlich kann man mit C objektorientierung nachbilden, genau so wie man's z.b. mit assembler (und ich denke auch JS) machen kann.
JS hat OOP-Tools schon von Haus aus :p
Aber ja: Standardmäßig hat C keine Möglichkeiten um mit OOP umzugehen. Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
OOP ist vor allem eine Denkweise (und weniger eine Compiler Technik
), wenn man dazu die passenden Tools hat oder entwickelt, dann kann man OOP in fast jeder Sprache betreiben. Ich verstehe überhaupt nicht, warum die Diskussion sich fast ausschließlich um Tools dreht. Es geht ums Denken! (Und ich denke sicher nicht über so was konkretes wie Laufzeit oder Statischen Polymorphismus nach, wenn ich mir Objekte und die Nachrichten zwischen ihnen im Kopf zusammen lege).
-
rüdiger schrieb:
Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
-
rüdiger schrieb:
Es geht ums Denken! (Und ich denke sicher nicht über so was konkretes wie Laufzeit oder Statischen Polymorphismus nach, wenn ich mir Objekte und die Nachrichten zwischen ihnen im Kopf zusammen lege).
stimmt schon was du sagt, aber letztendlich muss aus einer objektorientierten denkweise kein objektorientiertes programm entstehen. denn wenn man mal den abstraktionslevel runterschaltet, kann man Xin auch verstehen, der statischen polymorphismus als nichtig erklärt. aus 'low-level' sichtweise ist statischer polymorphismus nur eine optimierung, die polymorphismus beseitigt, wo eigentlich keiner sein muss. d.h. eine übertrieben objektorientierte denkweise für die maschine vereinfacht und nur noch 'echten' polymorphismus übrig lässt.
-
Doktor Prokt schrieb:
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
Erinnert mich irgendwie hieran:
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html
-
Doktor Prokt schrieb:
rüdiger schrieb:
Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
Ja, natürlich. Lisp arbeitet ja eh bei dem Tool Prinzip komplett andersrum, als Sprachen wie C++ oder Java. Eben aus der Richtung des Denkens, was ich ja gesagt habe. (Deswegen rate ich ja auch Xin sich mal mit anderen Sprachen zu befassen)
-
DEvent schrieb:
Otze und Shader haben gesagt das der JS und Template Code das gleiche ist, wie der C++ und der Java Code, ich stimmt mit ihnen nicht ueberein, weil man diese Beziehung in JS/Tpm gar nicht abbilden kann. Das wars.
Klar kann man es abbilden und es wird abgebildet - aber eben nicht so wie du es erwartest.
Die Abbildung findet über die Schnittstellendefinition statt.
Wir sagen: Dynamo ist eine Energiequelle.
In Java implementiert man das: alles was das Interface Energiequelle implementiert, ist eine Energiequelle.
In JavaScript implementiert man das: alles was sich wie eine Energiequelle verhält, ist eine Energiequelle.Der Ansatz ist etwas unterschiedlich. Aber dennoch stehen Dynamo und Atomreaktor in einer Beziehung - diese wird nicht direkt im Source Code durch Inheritance oder ähnliche Mechanismen implementiert, sondern es wird als "abstraktes Konzept" betrachtet.
Es gibt keine Energiequelle - es gibt nur Sachen die sich wie Energiequellen verhalten. Selbes Prinzip wie in Java: es gibt keine konkrete Energiequelle - es gibt nur unterschiedliche Ausprägungen.
Eine Beziehung muss nicht direkt im Soucrcode vorhanden sein. Denn SourceCode ist nur eine Ebene - daraus macht der Compiler dann zB C Code und dann wird daraus Assembler Code gemacht und dann erstmal Opcode und den emuliert die CPU dann auf eine eigene Opcode Sprache. Weiters ist der Source Code ja auch nicht die oberste Ebene: es gibt diverse Planungstools, UML oder Gedankengänge die Ebenen höher als der Source Code liegen.
Wo genau muss nun die Beziehung direkt im Code stehen - wo setzt man die gültige Ebene an?
Unsere Behauptung ist nun: diese Beziehung muss im Geiste da sein und das Programm muss nach dieser Beziehung modelliert werden. Ob diese Beziehung nun als Interface im Code vorkommt oder nicht, ist nach unserer Definition implementationsabhängig - ändert aber nichts an dem Gedanken hinter dem Code.