Performancemythen?

Shade Of Mine

Xin schrieb:

Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache.

Sehe ich überhaupt nicht. In Assembler Code steht uU so etwas:

void draw(Class* p) {
  switch(p->type) {
  case TRIANGLE_CLASS:
    return triangle_draw(p);
  case CIRCLE_CLASS:
    return circle_draw(p);
  }
  return pure_virtual_function_called_error();
}

Wenn man nun daran OO Code definieren will...

Aber OK, wenigstens habe ich jetzt eine Ahnung was für dich OOP. Wo sich diese "Definition" komplett beißt ist Pseudo Code. Man kann keinen OO-Code skiziieren weil es keinen Compiler gibt der ihn versteht. Naja - ok.

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

Lies dir den Thread am besten in 5 Jahren nochmal durch - vielleicht bist du dann weit genug OOP auf einer abstrakteren Ebene zu verstehen.

Brutus

Viel beeindruckender ist doch eher, dass er den ganzen Quatsch, den er hier andauernd versucht herunterzubeten, sogar ernst meint. Er ist fest davon ueberzeugt. Mit Trollen hat das schon lange nichts mehr zutun, dennoch vermag mir gerade ein praeziser Begriff dafuer nicht einfallen.

Undertaker

Shade Of Mine schrieb:

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

das kannste so nicht sagen. nach Xin's definition wäre ein assembler-code mit indirekten sprüngen 'JMP [R0]', d.h. die nächste position des instruction pointers wird zur laufzeit berechnet, durchaus objektorientiert.

this-*gt*that

Gabs die letzten 40 Seiten irgend ne brauchbare Erkenntnis?

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

Undertaker

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

evilissimo

Tellerrand schrieb:

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

Ich sag nur Singleton

evilissimo

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

LISP ist da dann das gegenbeispiel

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

Wozu gibt es dann die Klasse Class?
Na ganz so einfach würde ich es mir nciht machen

Shade Of Mine

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

Eine Klasse kann ein Objekt sein - sie muss aber nicht.

Undertaker schrieb:

in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html :p

Undertaker

Shade Of Mine schrieb:

Eine Klasse kann ein Objekt sein - sie muss aber nicht.

doch ist ein Object schrieb:

Undertaker schrieb:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html :p

tja, da seht ihr's....

Jester

Xin schrieb:

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.

Ich sagte nicht, dass Du den Parameter dazuerfunden hättest, sondern dass Du dazuerfunden hast, dass dieser bei mir eine wichtige Rolle spielt. Ich berufe mich nicht auf den ersten Parameter. Das ist Deine eigene Erfindung bzw. Einbildung.

edit: achso, er hat's aufgegeben oder eingesehen... na dann. auch gut!

rüdiger

this->that schrieb:

Gabs die letzten 40 Seiten irgend ne brauchbare Erkenntnis?

Es gab sicher ein paar nette Informationen, die aber leider in der Trollerei von Xin untergegangen sind.

this-*gt*that

Das erstaunt mich immer wieder, dass in diesem Forum so endlos lange über total banale und überflüssige Dinge diskutiert wird, wobei am Ende eh nichts rauskommt^^

Undertaker

this->that schrieb:

Das erstaunt mich immer wieder, dass in diesem Forum so endlos lange über total banale und überflüssige Dinge diskutiert wird, wobei am Ende eh nichts rauskommt^^

solange alle beteiligen ihren spass dran haben, ist es doch okay...

this-*gt*that

Ich bezweifle stark, dass alle wirklich Spaß daran haben.

Das Problem mit der Performance ist, dass sehr viele Leute auf verdacht optimieren. Der am besten optimierte Code bringt nix, wenn er nur 1% der Laufzeit ausmacht.

DEvent

Bin jetzt auf Seite 37:

Shade Of Mine schrieb:

Beide Codes machen exakt dies. Für Leute wie dich, die nur Java/C++ kennen ist die Idee kein Interface zu haben erschreckend. Für Leute die nur JavaScript kennen ist die Idee ein Interface Energiequelle zu haben erschreckend.

Das stimme aber nicht.

Shade Of Mine schrieb:

Ich kann in JavaScript garkeine "Klasse" Energiequelle einbauen - die Sprache würde es nicht unterstützen - ich müsste hacks verwenden damit das halbwegs gut läuft.

Was bei diesem Code aber viel wichtiger ist, ist nicht die Implementierung - denn die Implementierung hängt sowieso komplett von der Plattform ab. Mehr dazu weiter unten.

Das wichtige ist die Idee und die Aussage des Codes. Beide lösen ein Problem:
Ich habe eine Lampe und habe unendlich viele Energiequellen die ich beliebig kombinieren will.

In JS und bei der Template Programmierung hast du eine Lampe und die kannst du mit allem kombinieren, nicht nur mit Energiequellen.

Genauso an otze, wo ist den die Beziehung Klasse2 ist eine Klasse1 bei dem Templates?

Seite 38

Jester schrieb:

Hm, das muß ich bis jetzt überlesen haben. Wo definiert er, was ein Objekt ist? Soweit ich das überblicke verwendet er diesen Begriff als Blackbox. Im Gegenzug haben hier einige schon erklärt was ein Objekt sein soll und das Konzept OOP dann dadurch beschrieben, dass Objekte verwendet werden. Zudem unterscheiden wir uns in der Auslegung des Begriffs "Beziehung zwischen Objekten". Für Xin muß diese Beziehung (warum auch immer) Vererbung bedeuten. Andere wollen da auch Komposition und Aggregation dazuzählen. Was ist daran nun unpräzise und mystisch?

Tolle Definition. OOP ist also wenn man irgendwas mit Objekten macht. Was macht man den damit? Wieso macht man es mit ihnen? Und welche Techniken werden dabei verwendet?

Wieso sollte ein Objekt keine "Blackbox" sein? Ein Object ist sogar eine "Blackbox", weil ich die interne Implementierung nicht sehen kann.

Edit: Grad gelesen das Xin den Thread aufgibt. Dann schaffen wir die 50 Seiten wohl nicht mehr...

Shade Of Mine

DEvent schrieb:

Bin jetzt auf Seite 37:

Shade Of Mine schrieb:

Beide Codes machen exakt dies. Für Leute wie dich, die nur Java/C++ kennen ist die Idee kein Interface zu haben erschreckend. Für Leute die nur JavaScript kennen ist die Idee ein Interface Energiequelle zu haben erschreckend.

Das stimme aber nicht.

Dann erklär mir den Unterschied.

In JS und bei der Template Programmierung hast du eine Lampe und die kannst du mit allem kombinieren, nicht nur mit Energiequellen.

Genauso an otze, wo ist den die Beziehung Klasse2 ist eine Klasse1 bei dem Templates?

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?