Hat OOP nur Vorteile?

[Zudomon]

Hallo,

wie die meisten sicher wissen, arbeite ich an einer 3D-Engine. Dabei überkommt mich immer wieder das Gefühl, dass es ohne OOP eventuell aufwendiger, aber auch von der Ausführungsgeschwindigkeit besser sein könnte.

Viele sehen ja darin kein Problem, vor allem nicht, unter dem Aspeckt einer "Hobby-Engine". Aber was ist, wenn man versuchen möchte mit professionellen Engine gleich zu ziehen?

Hier wird gezeigt, wie viel Speed man noch so raus holen kann, wenn man nicht ganz so extrem OOP verwendet:
http://research.scee.net/files/presenta ... CAP_09.pdf

Was sagt ihr dazu?

Gruß
Zudo

[hagbard]

OOP ist ein weites und schwieriges Feld. ;)
Grundsätzlich halte ich es aber immer sinnvoll ein Problem mit Mitteln der Objektorientierung zu modellieren. Gerade bei professionellen Anwendungen ist umso wichtiger dass möglichst gut wart- und wiederverwendbarer Code rauskommt. Welche Features der OOP hingegen man dann im konkreten Fall nutzt hängt wiederum von einer Vielzahl von Randbedingungen ab (verwendete Sprache, Compiler, HW-Plattform, Os etc.) so dass ich es nicht für möglich halte da pauschale Aussagen zu treffen.
Für eine Hobbyanwendung hingegen würde ich persönlich nicht soviel Zeit in Design-Paradigmen investieren und versuchen eher schnell zu einen Ergebnis zu kommen. ;)

[anonym]

Bezieht sich das ganze auf die Cell-Architektur? Out-Of-Order-Architekturen dürften zumindest hinsichtlich der Branch-Prediction nicht so extrem Einbrechen. Finde die Quelle nicht mehr, aber irgendein Hersteller hat mal kundgetan, dass Playstation3-Entwicklung 5x so aufwendig/teuer ist wie CPU-Entwicklung, XBox360 bisschen weniger als PS3 und GPU 10x so viel. Allerdings loht sich diese Optimierung natürlich, wenn auch nicht im gleichen Ausmaß, dann auch für x86-Prozessoren.

[Krishty]

Bezieht sich das ganze auf die Cell-Architektur? Out-Of-Order-Architekturen dürften zumindest hinsichtlich der Branch-Prediction nicht so extrem Einbrechen.

Der Artikel führt afaik nicht Branch-Prediction als Argument gegen OOP an, sondern Cache-Misses. Er zeigt ja an irgendeiner Stelle, dass durch Cache-Misses bedeutend mehr Zeit verloren wird (oder gewonnen werden kann) als durch Sprungvorhersage.

Gruß, Ky

[Lynxeye]

Ich halte es für einen Fehler auf gut verständlichen Code zu verzichten, nur um es der CPU einfacher zu machen. Ich erlebe es zur Zeit immer wieder bei den Userspace Grafiktreibern für Linux. Die sind komplett in C programmiert, obwohl eigentlich ein Objekt orientiertes Design angewendet wird nur um die V-Table zu vermeiden. Dafür ist der Code einfach nur extrem schwer verständlich und schreckt neue Entwickler ab.

Ich bin der Meinung, dass wir uns mehr auf (evtl. auch zukünftige) Compileroptimierungen verlassen sollten, als alles per Hand zu optimieren. Wenn ein Compiler das Speicherlayout noch nicht ordentlich hinbekommt ist das ein Problem, was es im Compiler zu lösen gilt und nicht in jedem einzelnem Programm wieder und wieder.

[Aramis]

Ausserdem: auch die im Artikel angesprochenen 'Optimierungen' koennen mit OO umgesetzt bzw. sogar versteckt werden … schlussendlich bezieht sich die Kritik auf fette Szenengraphen mit gottaehnlichen Knoten, nicht auf OOP allgemein :-)

[Zudomon]

Also ich habe das Gefühl so langsam auf einen unausweichlichen Scheideweg zuzugehen.

Damals habe ich versucht OOP zu vermeiden. Hatte da ein wenig mit Delphi rumgetestet und da waren es soweit ich mich erinnere etwa 30% weniger Speed, wenn ich Klassen assoziert habe. Deswegen hat sich bei mir eine mehr oder weniger große Abneigung dagegen manifestiert. Vor allem habe ich dann immer auf die Engines vom Carmack rübergeschielt, die ja damals noch in C programmiert waren und extrem viel Speed gegenüber anderen Engines hatten.

Wenn ich mir Vorstelle, ich hätte ne Million Vektoren, dann kostet das allokieren natürlich schon etwas Zeit. Aber wie ist es, wenn man einfach einen großen Speicherblock erstellt und diesen nur Imaginär in XYZ Komponenten aufteilt? Das sollte doch um ein vielfaches schneller sein. Auch einmal über alle wegiterieren sollte dabei ja wesentlich schneller gehen, als wenn man im Speicher von Instanz zu Instanz springen muss.

Dabei würde ich gerne OOP benutzen. Meinen ModifierStack habe ich z.B. über ein Decorator Pattern realisiert. Auch wäre es wesentlich einfacher, alle Vertices, Kanten und Polygone über Klassen zu verwalten. Aber mir grauts halt vor möglichen Geschwindigkeitseinbusen. Ein solcher Schritt wäre nicht gerade einfach und wenn ich am Ende dadurch zwar mehr Codeübersicht habe, dafür aber alles grottig langsam wird, dann will ich das unbedingt vermeiden.

[Schrompf]

Da brauchst Du Dir keine Sorgen zu machen, denke ich. Ich kenn mich jetzt nicht mit Delphi aus, aber ich vermute, da gibt es ähnliche Mittel. Du scheinst anzunehmen, dass man Objekte nur auf dem Heap anlegen kann. Du kannst aber auch Objekte anlegen wie Strukturen auch: einzeln, als Array, einzeln auf dem Heap oder als Array auf dem Heap. Nur halt besser gekapselt.

Und Code wie

Code: Alles auswählen

Vector3D a( 3, 4, 5), b( 0, 2, 3);

a += b;

ist auf der CPU in jeder Hinsicht identisch zu

Code: Alles auswählen

struct Vector3D a, b;
a.x = 3; a.y = 4; a.z = 5;
b.x = 0; b.y = 2; b.z = 3;

a.x += b.x; a.y += b.y; a.z += b.z;

einen sinnvoll inlinenden Compiler vorausgesetzt. Ich persönlich sehe in OOP nur Vorteile. Manchmal ist die imperative Programmierweise wie in C gleichwertig, aber nie besser. Und es zwingt einen ja keiner dazu, *alles* als Klasse zu verpacken.

[Tactive]

Ich denke bei der Softwareentwicklung auch immer eher an die Usability, also wie kann ich einmal programmiertes wiederverwerten. Das bedeutet nun nicht, das ich Klassen x-Fach vergewaltige aber es erleichtert doch allgemein wenn ich für ein Problem schon eine Teillösung anwenden kann und nicht wieder von vorne anfangen und wohlmöglich dafür Quellcode irgendwoher kopieren muss. Gerade bei einer Engine wäre es mir wichtig mich dadurchzufinden, da ist die Perfomance eher Nebensache. Neulich habe ich noch in den Doom 3 Source von Carmack geschaut (aus Neugierde) und wusste gar nicht wo das Ding anfängt und wo es aufhört.
Da ist mir eine OOP Lösung dann doch lieber, auch wenn man sich sicherlich im klaren sein muss das man damit auch viel Unfug anstellen kann wenn man nicht aufpasst.

Schließe mich aber auch der Meinung von Lynxeye an, das einige Aufgaben mal so langsam vom Compiler gelöst werden sollten anstatt das man als Programmierer jedesmal das Rad neu erfinden und wilde Workarounds zusammenhacken muss.

[Krishty]

An object is a dynamic instance of a class. An object is always allocated dynamically, on the heap, so an object reference is like a pointer (but without the usual Pascal caret operator). When you assign an object reference to a variable, Delphi copies only the pointer, not the entire object. When your program finishes using an object, it must explicitly free the object. Delphi does not have any automatic garbage collection (but see the section "Interfaces," later in this chapter).

(Quelle) Stimmt das? Man kann nicht beliebig auf dem Stack anlegen und alle Objekte sind Referenzen? Wenn dem so ist, kann ich die 30 % Geschwindigkeitseinbuße verstehen … damit würde Schrompfs Beispiel zu dem hier werden:

Code: Alles auswählen

struct Vector * a, b;
a = malloc(sizeof(Vector)); b =  malloc(sizeof(Vector));
a->x = 3; a->y = 4; a->z = 5;
b->x = 0; b->y = 2; b->z = 3;
a->x += b->x; a->y += b->y; a->z += b->z;
// und automatische Freigabe gibt es auch nicht.

In dem Fall ist die Sprache scheiße (fast wie Java, nur dass es nicht managed ist) und – so gern ich hier auch OOP predigen würde – ich selber würde das class-Schlüsselwort an einen Elektroschocker koppeln …

[Zudomon]

Also ich kann dir das nicht mit 100%tiger Sicherheit sagen, aber jedes Objekt muss mit Create erstellt und mit Free wieder abgerissen werden. Da mir sonst auch keine andere Möglichkeit bekannt ist, eine Klasse einfach auf dem Stack zu erzeugen würde ich sagen, es ist nur Heap möglich. Man bekommt durch das Create ebend die Speicherstelle zurück. Dieser Pointer wird versteckt in der Variable für die Instanz. Also es stimmt, das jede Instanzvariable nur eine Referenz ist.
Aber so ganz verstehe ich dabei jetzt nicht, warum es so schlimm ist? Man kann sehr leicht Instanzen hin und hergeben ohne sich mit diversen Pointern zu verpointern.

[Schrompf]

Aber so ganz verstehe ich dabei jetzt nicht, warum es so schlimm ist? Man kann sehr leicht Instanzen hin und hergeben ohne sich mit diversen Pointern zu verpointern.

Hm? Du hast doch selbst geschrieben, was daran so schlimm ist: geschätzte 30% Performance-Verlust. Bei so kleinen Sachen wie Vektoren wahrscheinlich mehr.

Abgesehen davon sprich da ja nix dagegen. Außer dass das halt Pointer sind, was Du da benutzt, egal, welchen Namen die dafür haben. Verpointern im Sinne von Resourcen-Lebenszeit und Verweise auf invalide Instanzen geht also genauso. [edit] Vorausgesetzt, Delphi hat manuelle Resourcenverwaltung und keinen Garbage Collector. Ich glaube, das irgendwo mal gelesen zu haben. Wenn ein Garbage Collector im Hintergrund arbeitet, kannst Du Dich wirklich nicht mehr "verpointern", höchstens noch Speicherlecks produzieren.

[Alexander Kornrumpf]

An object is a dynamic instance of a class. An object is always allocated dynamically, on the heap, so an object reference is like a pointer (but without the usual Pascal caret operator). When you assign an object reference to a variable, Delphi copies only the pointer, not the entire object. When your program finishes using an object, it must explicitly free the object. Delphi does not have any automatic garbage collection (but see the section "Interfaces," later in this chapter).

(Quelle) Stimmt das? Man kann nicht beliebig auf dem Stack anlegen und alle Objekte sind Referenzen? Wenn dem so ist, kann ich die 30 % Geschwindigkeitseinbuße verstehen

Ja, Delphi ist so. Man darf bei Delphi aber auch nie den Hintergrund vergessen aus dem es entstanden ist. Ich habe eigentlich immer recht gerne damit gearbeitet, auch wenn es keine praktische Relevanz hat.

[Lynxeye]

Die grottige Performance und der so gut wie nicht optimierende Compiler war für mich immer ein Grund Delphi zu hassen, als ich es im Informatiksysteme Leistungskurs benutzen musste.

[Krishty]

Um mal das Objekt-Speichermanagement von Delphi zusammenzufassen:

• Alle Objekte werden auf dem Heap abgelegt und Referenzen werden herumgereicht. Ich bin mir nicht ganz sicher, ob auch Arrays Blöcke von Referenzen sind, aber das würde gut in das Sprachkonzept passen.
• Alle Objekte verfügen über einen Virtual-Method-Table mit Typinformationen, bzw. einen Zeiger zu diesem und über Reference Count.
• Der Heap ist (wie bei jeder Sprache ohne Stack) für solche Mikro-Allokationen optimiert und ähnelt in der Implementierung dem Win32-Low-Fragmentation-Heap ohne zusätzliche Features (Sicherheit).

Insofern ist es managed Languages à la Java sehr ähnlich. Eine Klasse anzulegen, um 3D-Vektoren zu speichern, wäre tatsächlich katastrophal: Jeder Vektor wäre Heap-allokiert (wenngleich auch durch den Low-Fragmentation-Heap nicht so schlimm verstreut, wie man es vermuten würde) und hätte global gesehen durch VMT, Reference Count und Allokation einen Speicher-Overhead von mindestens 60 %. Das pflanzt sich dann fort, weil eine Vertex-Klasse wieder aus drei Vektor-Referenzen für Position, Normale und Texturkoordinate bestünde usw.

Ganz so schlimm ist die Situation dann aber doch nicht: Es gibt – scheinbar vor allem genutzt, um mit ABIs kompatibel zu bleiben – records. Das waren ursprünglich reine Datenstrukturen und können aber auch auf dem Stack abgelegt werden; haben keinen Overhead wie VMTables oder RCounting. Die Arbeit mit records ist nahezu identisch mit C-structs (was wohl auch das Ziel ist, schließlich werden damit C-structs und sogar unions z.B. mit der WinAPI ausgetauscht). Seit Delphi 2006 können sie offenbar auch Konstruktoren und Methoden haben (wenn auch nur non-virtual und ohne Vererbung) und dürften damit Overhead-freie OOP zumindest auf dem Level C mit class erlauben. Das hat Delphi in dieser Hinsicht Java vorweg (und ist damit auch nicht mehr so scheiße, um das von oben zurückzunehmen), man muss halt nur die Finger von class lassen, sonst ist man ruck, zuck wieder bei den 30 %.

Es gibt übrigens auch die Möglichkeit, im Konstruktor alte Objekte wiederzuverwenden statt neue anzulegen (die Hackerei im Speicher-Manager sah aber nicht gerade angenehm aus). Da die WinAPI voll zur Verfügung steht, kann man auch selber Speicher allokieren und verwalten; ob inwiefern der nutzbar ist um Objekte drauf anzulegen, weiß ich aber nicht.

Auch über die optimierfähigkeit des Compilers kann ich nicht viel sagen.

Wäre schön, wenn Zudomon mögliche Fehler in meinen Annahmen korrigieren könnte.

[Zudomon]

Aber so ganz verstehe ich dabei jetzt nicht, warum es so schlimm ist? Man kann sehr leicht Instanzen hin und hergeben ohne sich mit diversen Pointern zu verpointern.

Hm? Du hast doch selbst geschrieben, was daran so schlimm ist: geschätzte 30% Performance-Verlust.

Für mich ist das so schlimm, der Performance-Verlust. Aber meine Aussage war ja auf die von Krishty bezogen, der es scheiße fand, wenn ich richtig verstanden habe, dass alle Klassen als Pointer gehandhabt werden.

Krishtys Beitrag möchte ich so stehen lassen. Er beschäftigt sich immer akribisch mit der ganzen Materie! :)
Ich hingegen nur sehr oberflächlich...

So langsam überlege ich, ob ich nicht doch auf eine andere Sprache wechsel, wenn Delphi letztlich doch so mistig ist. :(

[Schrompf]

Wikipedia meint, dass Delphi-Programmierer ihre Instanzen manuell wieder löschen müssen. Es scheint also keine Referenzenzählung zu geben.

Das wäre dann ja die Vereinigung der blödesten Eigenschaften aller Programmiersprachen - der Zwang zur Heapallokation wie in verwalteten Sprachen, kombiniert mit der Mühseligkeit von C++ bei der Resourcenverwaltung. Immerhin helfen die von Krishty genannten records, den Aufwand ein wenig zu dämpfen.

[Krishty]

Naja, schlimm ist, wie gesagt, der Overhead. Statt einen durchgängigen Block Speicher für hundert Vektoren zu allokieren, würden hundert einzelne Speicherstellen für Vektor-Objekte reserviert, die u.U. verstreut herumliegen und in der Gesamtheit fast doppelt so viel Speicher verbrauchen. Jeder Zugriff auf einen Vektor würde eine Indirektion bedeuten – du bräuchtest einmal die Speicherstelle der Referenz und müsstest von ihr aus auf die Speicherstelle des Objekts schließen. Für den Cache ist das natürlich katastrophal; wie im PS3-Paper, nur viel viel schlimmer.

Wie gesagt kannst du das bei Delphi ja glücklicherweise durch records umgehen. Bei anderen Sprachen kann es OOP und gute Performance sich gegenseitig ausschließen lassen.

Zum Wechsel auf andere Sprachen kennst du meine Meinung – die meisten sind scheißerer, viele nur marginal weniger scheiße, und die, die bedeutend weniger scheiße sind, sind dafür scheiße schwer zu beherrschen. Für die paar Milisekunden lohnt es sich nicht, alles neu (und bei einer neuen Sprache zwangsläufig nochmal komplett falsch) zu machen.

Wikipedia meint, dass Delphi-Programmierer ihre Instanzen manuell wieder löschen müssen. Es scheint also keine Referenzenzählung zu geben.

Doch. Man muss jede Instanz manuell freigeben, aber tatsächlich zerstört wird erst, wenn der Referenzzähler Null erreicht – damit nicht gelöscht werden kann, was anderswo noch benutzt wird; denn man reicht ja überall Zeiger herum. Edit: Siehe auch hier.

[The_Real_Black]

Da frage ich mich als C#ler gibt es was anderes als OOP? *grins*
Welche Nachteile hat es wenn man nicht OO programmiert? Genügend.
Ohne Objekte bzw deren Klassen muss man sich immer Funktionen für die einzelnen Strukturen überlegen und diese als Zusatz Parameter übergeben. Für mich ist der Logische Vorteil bei der objektorientierten Programmierung ausschlaggebend, denn Klassen und Objekte sind leichter zu überblicken und zu entwerfen. Die Vorteile bei einer Flachen Hierarchie aus dem PDF sind schön, aber wenn man eine Dynamische Hierarchie hat kommt man nur mit Referenzen oder Pointern zurecht bzw wenn man den Baum erweitern will hat man dort viel Zeitverlust.
"Aber was ist, wenn man versuchen möchte mit professionellen Engine gleich zu ziehen?"
Man sollte immer auf eine saubere (Klassen)Struktur in seiner Engine setzen als über "dirty Hacks" zu Optimieren zu versuchen.

[Krishty]

Ohne Objekte bzw deren Klassen muss man sich immer Funktionen für die einzelnen Strukturen überlegen und diese als Zusatz Parameter übergeben.

Mit Objekten und Klassen musst du dir die Funktionen immernoch überlegen, nur, dass sie nun „Methode“ genannt werden und du den zusätzlichen Parameter nicht übergibst, sondern vor den Aufruf schreibst. Selbst dann, wenn du ihn nicht brauchst (static).

Für mich ist der Logische Vorteil bei der objektorientierten Programmierung ausschlaggebend, denn Klassen und Objekte sind leichter zu überblicken und zu entwerfen.

Ohne OOP gibt es noch viel weniger zu überblicken, da du viel weniger Datentypen hast und alle Vererbungsbeziehungen entfallen. Das eigentliche Überblicksproblem ist, welche Daten von welcher Funktionalität berührt werden (Stichwort Wirkung) und wie man sie zum Aufruf kriegt … da tun sich OOP und imperative Sprachen nichts:
Bei OOP muss ich immer davon ausgehen, dass ein Objekt als Ganzes verändert wird, wenn ich eine Funktion damit aufrufe, weil ich es ja als Ganzes übergebe und das Innenleben abgeschottet ist (siehe Paper: Ich verarbeite tausend Objekte mit je zehn Eigenschaften, nur, damit eine davon (Bounding-Box) verändert wird – dass die Funktion nicht auch die restlichen neun verändert, kann ich kaum garantieren, es sei denn, ich führe Schnittstellen ein, die aber wieder Overhead bringen und die Hierarchie unnötig verkomplizieren, denn für was außer dieser einen Funktion sollte ein IBoundingBoxedGameObject schon nützlich sein). Bei prozeduraler Programmierung habe ich den perfekten Überblick über den Programm- und Datenfluss, nur muss ich eben alle Daten selber rauspfriemeln.

Das Übersichtsproblem bei OOP ist meiner Einschätzung nach nur die Folge davon, dass viele meinen, OOP gehöre überall erzwungen (Wenn ich das Minimum zweier Zahlen haben will, wo gehört die Funktion hin? Member einer Zahlen-Klasse? Aber die Funktion behandelt zwei Zahlen gleichwertig! Also static? Bullshit, das gehört nirgendwo als Member reingepackt. Nichts unterscheidet die Semantik von einem int-Mininum so sehr von einem float-Vektor-Minimum, dass explizit davor geschrieben gehört, welches man meint, es sei denn, man kann keine Funktionen überladen …) und dass manche Programmiersprachen das auch noch unterstützen (public static void main() ist eine der lächerlichsten Absurditäten in der ganzen Geschichte der Programmiersprachen).

Selbstverständlich kategorisieren Menschen ihre Umwelt, fangen an zu kapseln und zu sortieren. Aber es ist falsch, anzunehmen, dass sie nichts anderes täten. Pure OOP kann genauso hässlich und problematisch sein (lies: nicht mehr nachvollziehbar) wie pur imperative Programmierung, und ein exzellenter Artikel dazu ist der hier.

Die Vorteile bei einer Flachen Hierarchie aus dem PDF sind schön, aber wenn man eine Dynamische Hierarchie hat kommt man nur mit Referenzen oder Pointern zurecht bzw wenn man den Baum erweitern will hat man dort viel Zeitverlust.

Die flache Hierarchie lässt sich, wie Aramis schon sagte, auch mit OOP hervorragend und sauber „dynamisieren“ und Zeiger / Referenzen an sich sind nichts Schlimmes.

Man sollte immer auf eine saubere (Klassen)Struktur in seiner Engine setzen als über "dirty Hacks" zu Optimieren zu versuchen.

Ein Tor, wer behauptet, auf OOP zu verzichten sei ein schmutziger Hack. Die hoffnungslos überkapselte Klassenhierarchie mancher Java- und C#-Programme finde ich bei weitem besorgniserregender. Aber es stimmt natürlich, dass Sauberkeit vor Performance geht.

Sorry, dass das so rausbrach, aber bisher hatte sich keiner getraut, nicht-OOP-Programmierung so deutlich zu kritisieren. Ich habe jetzt auch eine Vermutung, warum ;)

[eXile]

"There ain't no such thing as a free lunch" gilt natürlich auch für die OOP. Wovor ich mich am allermeisten fürchte, ist der sog. Inner-Platform-Effect, d.h. man legt die Freiheitsgrade der Software so allumfassend an, dass man das gesamte System eigentlich ein zweites Mal nachbaut. Oder Kurz: "Alles muss anpassbar sein." ist der Tod.

Dabei ist das Festlegen bzw. die Einschränkung der Freiheitsgrade von Software doch genau das, was überhaupt eine sinnvolle Implementierung zulässt. Aus diesem Grunde auch noch einmal ein Daily WTF.

[hagbard]

Delphi ist eine nette Sprache um GUI-Frontends zu basteln. Für wirklich rechenintensive Sachen muss man da echt aufpassen. Ähnlich wie Java verleitet es einen dazu ständig Construktoren und Destruktoren aufzurufen und damit Speicher umherzuschieben was tatsächlich auf die Performance gehen kann. Klar kann man in Delphi auch prozedurales Pascal programmieren womit man mehr Kontrolle über die Performance hat ist ja ähnlich wie C++ nur ein prozedurale Sprache wo im nachhinein ein wenig Objektorientierung drangefriemelt wurde. :twisted:
Was die Benutzung von Arrays angeht wird zwischen dynamischen und statischen unterschieden. Dynamische werden wie Objekte behandelt während statische nicht anderes behandelt werden als C-Arrays.

[Lars]

Hier noch ein paar weitere Informationen zu Delphi:

Bei Delphi ruft der Constructor die virtuelle Klassenmethode NewInstance (wie virtual nur pro Klasse statt pro Objekt) auf, um den Speicher zu belegen. Diese Methode kann man überschreiben und selber einen Pointer zurückgeben. Damit kann man das Object zwar nicht unbedingt auf dem Stack speichern, aber z.B. einen eigenen Allocator für kleine Objekte einrichten. Natürlich macht es alleine schon wegen der Referenzsemantik keinen Sinn Vectoren als Klasse zu erstellen. Wie bereits erwähnt gibt es dazu die Records, die dann auch Operatoren und einen automatischen Constructor/Destructor unterstützen.

Normale Objekte werden nicht per Referenz verwaltet, sondern explizit erstellt und freigegeben. Mit FreeAndNil gibt es einen eingeschränkten Schutz vor doppeltem Freigeben. Interfaces sind wie in C# oder Java seperate Typen. Das Basisinterface ist das gleiche wie bei COM und hat auch die Methoden AddRef/Release und QueryInterface. Der Compiler erzeugt bei der Verwendung von Interfaces die entsprechenden Aufrufe, so dass man COM Objekte sehr einfach verwenden und auch für eigene Klassen Referenzzählung implementieren kann. Echte Mehrfachvererbung wie in C++ ist nicht möglich, aber man kann die Implementation eines Interfaces dynamisch an einer Variable innerhalb der Klasse delegieren. Damit ist zumindest Komposition möglich.

Die dynamischen Arrays werden auch automatisch per Referenzzählung verwaltet. Da es früher keine Generics in Delphi gab, war das eben eine Alternative zum std::vector.

Die Standardaufrufkonvention ist Register. Im Gegensatz zu FastCall werden aber 3 Register verwendet. Ab der Version 2005 können Funktionen auch geinlined werden.

Zu dem PDF:
Solche Strukturen kann man auch sehr gut mit OOP realisieren. Z.B. ist es denkbar ein Prozessnetzwerk aus Rechenknoten und Queues aufzubauen. Über standardisierte Interfaces können diese dann verbunden werden. Der Vorteil wäre vermutlich, dass man solch ein Netzwerk leicht auf mehrere Kerne verteilen kann.
Z.B. hat man hier Java um solche Konstrukte erweitert: http://groups.csail.mit.edu/cag/streamit/

[Ledin]

Man muss hier schon auch zwischen den Sprachen unterscheiden.
Java ist beispielsweise ziemlich puristisch, was OOP angeht. Selbst main() gehört in ein Objekt, und es gibt keine echten selbstdefinierten Wertetypen.
C# erlaubt deutlich mehr, wie z.B. unsafe regions für Pointer-Gefummel und echte selbstdefinierte Wertetypen.

In der Theorie bietet damit C# dem Programmierer mehr Möglichkeiten, wenn es mit der Performance tatsächlich einmal eng werden sollte.
Aber das Grundproblem des Threads ist ja ein ganz anderes. Der Threadersteller sollte sich keine Sorgen um Performance machen, wenn er
eine eigene Engine schreiben will. Es ist wichtig, dass die Engine erst einmal funktioniert und halbwegs sauber aufgebaut ist.
Das ist mit OOP leichter als mit prozeduraler Programmierung in C. Ich würde heute keine Engine mehr in reinem C anfangen,
das tun auch viele Top-Leute nicht mehr. Bei der heutigen Menge an Code ist es vermutlich zu schwierig, den vollen Überblick zu behalten.
Für mich sowieso, ich kann reines C nicht besonders gut lesen. Kann daran liegen, dass es hässlicher C-Code war, ich weiß es nicht.

Der Punkt ist, dass die Performance erst einmal zweitrangig ist. Natürlich kann man auch mit OOP eine schnelle Engine schreiben.
Das Stichwort ist hier Optimierung. Da bekanntermaßen ein durchschnittliches Programm 80% seiner Zeit in 20% des Codes verbringt,
muss man bei Performance-Problemen eben den Profiler anwerfen, die 20% finden und optimieren.
Dann ist man auch natürlich mit OOP schnell genug. Man darf eben auch nicht vergessen, dass reine C-Compiler nicht mehr wirklich
weiterentwickelt werden, C++-Compiler beispielsweise schon. Sie sind heute schon so gut im Optimieren, dass ein großer Teil des
OOP-Overheads praktisch nicht mehr existiert. Heute ist Flexibilität wichtiger, Rechenpower ist ohnehin zur Genüge verfügbar,
wenn man mal von low-level Grafikprogrammierung absieht.
Auf Game logic-Seite beispielsweise ist Funktionalität wichtig, wenige Bugs. OOP kann hier helfen.
Was Besseres haben wir zur Zeit nicht.
Man sollte die rein prozedurale Programmierung langsam wirklich aufgeben für Projekte, die so groß sind wie Spiele oder Engines.
Ich krieg echt die Krise, wenn ich wieder in absurdes C-Gefummel reinsteppen muss.
Die prozedurale Programmierung verleitet halt nun mal auch zu unsauberem Stil...

[Thygrrr]

OOP hat schon seit Jahren kaum oder keine Auswirkungen auf die Performance. Der Compiler optimiert den code eh besser als jeder C-Programmierer das bei realistischen Projekten von Hand könnte (allein wegen der Tiefe der PIQ und der Größe und Strategien der immer schneller werdenden Caches).

OOP hat viele, viele Vorteile. Der größte ist die Ersparnis and Zeit bei Entwicklung, Erweiterung und Fehlersuche im entwickelten Code. Allein diese Ersparnis wiegt die Nachteile in der Regel vollständig auf.

Einige der Schwächen allerdings sind das Fragile Base Class Problem, sowie eventuelle Beschränkungen bei der Vererbung (in Java wünscht man sich manchmal Mehrfachvererbung, in C++ flucht man gelegentlich auch darüber).

Bei JavaME hat man das Problem, dass der Overhead von ~0.5 kb pro Klasse und ~16-32 bytes pro Objekt eventuell zu Speicherplatzproblemen entweder bezüglich der Größe des Programmcodes oder des genutzten Heaps führen könnte.

Dass in Virtual Machines die OOP besonders langsam sei, ist auch ein Gerücht - im Gegenteil! Insbesondere das Instanziieren und Zerstören von Objekten ist enorm schnell (eine, manchmal zwei Größenordnungen schneller als in Assembly oder C/C++), und auch viele Funktionsaufrufe sind, weil sich der JIT Compiler je nach bedarf Prolog und Branch Prediction neu hinbiegen kann, deutlich schneller wo es darauf ankommt.

Es stimmt, dass in spezifischen Codeabschnitten strukturierte Programmierung der objektorientierten überlegen ist; das gilt aber eher in besonders engen Schleifen oder aufwändigen Algorithmen (auf relativ kleinen Datenmengen "n", so dass die durch OOP eingeschleppte lineare Konstante mehr Auswirkung hat als das eigentliche Laufzeitverhalten des Algorithmus). Hoare hat aber demonstriert dass es eher auf letzteres ankommt als auf einen besseren Compiler etc. Verbessert erst Eure Algorithmen, dann erst den Code.

Es stimmt auch, dass OOP prinzipbedingt mehr Speicherzugriffe verursachen kann, vieles davon ist aber schlichtweg egal mittlerweile, oder wird von den heutigen hervorragenden Compilern gekonnt wegoptimiert.

[Krishty]

@eXile: Beängstigend-herrlicher WTF :D

@hagbard: Weißt du zufällig auch, wie Objekt innerhalb von Arrays verwaltet werden? Also, ob die Instanzen in einem kontinuierlichen Speicherblock liegen oder ob das Array nur ein Block von Referenzen ist?

Danke @Lars für die Infos, aber eine Frage hätte ich da noch:

Normale Objekte werden nicht per Referenz verwaltet, sondern explizit erstellt und freigegeben.

Du meinst, per Referenzzählung, oder?

Es ist wichtig, dass die Engine erst einmal funktioniert und halbwegs sauber aufgebaut ist. Das ist mit OOP leichter als mit prozeduraler Programmierung in C.

Der OP hat leider vergessen, zu schreiben, dass er momentan fast ausschließlich prozedurales Delphi schreibt … er würde also, bliebe er beim prozeduralen Ansatz, auch sicher nicht den Schritt zurück auf C machen :)

Man darf eben auch nicht vergessen, dass reine C-Compiler nicht mehr wirklich weiterentwickelt werden, C++-Compiler beispielsweise schon.

Nenn mir mal ein paar, die „nicht mehr wirklich weiterentwickelt werden“ – Von MS Visual Studios Seite wird immer wieder betont, wie sehr sie für die nächste Version ihres C-Compilers auf Kundenwünsche eingehen; gccs (in Kleinbuchstaben) Aufrüstung zu C99 ist fast abgeschlossen und ansonsten sind auch die meisten C++-Compiler in großen Teilen abwärtskompatibel, da ist es doch eh egal, ob ein Compiler ein reiner C-Compiler ist oder mehrere Sprachen unterstützt.

Dass in Virtual Machines die OOP besonders langsam sei, ist auch ein Gerücht - im Gegenteil! Insbesondere das Instanziieren und Zerstören von Objekten ist enorm schnell (eine, manchmal zwei Größenordnungen schneller als in Assembly oder C/C++)

Erklär mal, wie eine VM, die selber in C/++ geschrieben und zu x86-Assembly kompiliert wurde, 10× schneller ist als C/++/Asm.

Ansonsten war das Sezieren der Performance nicht in der Behauptung begründet, dass OOP generell langsamer sei, sondern gerade gegenteilig darin, dass die Sprache etwas vermurkst hat, wenn das der Fall ist. Mittlerweile steht ja fest, dass unoptimiertes Delphi mit möglichst vielen records ähnlich schnell sein sollte wie unoptimiertes C++ mit möglichst wenig virtual.

[The_Real_Black]

nur, dass sie nun „Methode“ genannt werden und du den zusätzlichen Parameter nicht übergibst, sondern vor den Aufruf schreibst. Selbst dann, wenn du ihn nicht brauchst (static).

Das Übersichtsproblem bei OOP ist meiner Einschätzung nach nur die Folge davon, dass viele meinen, OOP gehöre überall erzwungen (Wenn ich das Minimum zweier Zahlen haben will, wo gehört die Funktion hin? Member einer Zahlen-Klasse? Aber die Funktion behandelt zwei Zahlen gleichwertig! Also static? Bullshit, das gehört nirgendwo als Member reingepackt.

Bei prozeduraler Programmierung habe ich den perfekten Überblick über den Programm- und Datenfluss, nur muss ich eben alle Daten selber rauspfriemeln.

Selbstverständlich kategorisieren Menschen ihre Umwelt, fangen an zu kapseln und zu sortieren. Aber es ist falsch, anzunehmen, dass sie nichts anderes täten.

Ein Tor, wer behauptet, auf OOP zu verzichten sei ein schmutziger Hack. Die hoffnungslos überkapselte Klassenhierarchie mancher Java- und C#-Programme finde ich bei weitem besorgniserregender. Aber es stimmt natürlich, dass Sauberkeit vor Performance geht. Sorry, dass das so rausbrach, aber bisher hatte sich keiner getraut, nicht-OOP-Programmierung so deutlich zu kritisieren. Ich habe jetzt auch eine Vermutung, warum ;)

Schlimm wird dieser Parameter wenn es ein void Pointer ist, dann wird die Suche welche Struktur benötigt wird echt ein Problem oder es wird begonnen einen Unterteil einer "Klasse" herauszugeben damit dieser allein von einer Funktion verändert wird.

Ich würde eine eigene Sotierklasse verwenden. ^^

Genau und bei OOP sind die Daten sauber gehalten und man muss sie nicht "rauspfriemeln". Hier möchte ich auf Wie jagt man Elefanten hinweisen besonders, dass der Elefant seine Fang-Methoden selbst mitzubringen hat. Die Zuständigkeit über die Daten sind mit OOP hart geregelt, denn die Daten einer Klasse können (unter Vorraussetzung man macht alles privat) nur von ihren Methoden verändert werden.

"Sauberkeit vor Performance": Ich sehe deshalb den ersten Ansatz einer Engine immer in einer sauberen (Klassen-)Struktur wärend man die Performance nachträglich Optimieren sollte. Persönlich habe ich schon mal ein paar Leute die Fehlerprüfung zur Optimierung ausbauen sehen (nicht im beruflichen kontext, zum Glück). Bitter, aber für Extremfälle könnte man tatsächlich so weit gehen zb in der Demo Scene (http://www.pouet.net/) ansonsten gehört sich diese Art der Optimierung unter Androhung körperlicher Züchtigung verboten...
"Ich habe jetzt auch eine Vermutung, warum " Ich auch, aber für einen C#ler ist es schon ein Bruch darüber nachzudenken nicht OO zu programmieren.

Thygrrr: "Verbessert erst Eure Algorithmen, dann erst den Code." oder kapselt euren Algo so, dass man ihn später immer noch austauschen kann. Es ist zwar manchmal schwer für eine Aufgabe ein Interface zu definieren aber man sollte sich diese Option immer offen halten damit man auch verschiedene Algos nebeneinander laufen lassen kann zB verschiedene Traversierungen.
Neben den Algos sollte man auch die Datenstrukturen verbessern bevor man sie umsetzt. zB Baum soll es ein klassischer Baum sein 1:n Parent:Childs oder lieber nur das Erste Kind im Parent halten und der Nachbar auf der Ebene dann im Child.
Es gäbe so viel zu verbessern bevor man die ersten "Code"Optimierungen vornimmt. Frage ist wie sieht die Engine aus dem Eingangspost denn im Moment aus? Man könnte so gezielter überlegen was nun besser ist wenn die Engine bis jetzt ohne oop auskam sollte man nicht versuchen zwanghaft Klassen zu finden. Anderseits gilt es genau so wenn man bis jetzt Klassen hat sollte man nicht auf oop verzichen.

[Zudomon]

Frage ist wie sieht die Engine aus dem Eingangspost denn im Moment aus?

Öh... was soll ich darauf sagen?

[Krishty]

Schlimm wird dieser Parameter wenn es ein void Pointer ist, dann wird die Suche welche Struktur benötigt wird echt ein Problem oder es wird begonnen einen Unterteil einer "Klasse" herauszugeben damit dieser allein von einer Funktion verändert wird.

Auf OOP zu verzichten bedeutet in keinster Weise, auf Typisierung zu verzichten. (Eigentlich nicht einmal, Zeiger benutzen zu müssen.) Bei generischer Programmierung ist das u.U. anders, aber da führt OOP üblicherweise zu einer Schnittstellen-Explosion.

[…] bei OOP sind die Daten sauber gehalten und man muss sie nicht "rauspfriemeln". Hier möchte ich auf Wie jagt man Elefanten hinweisen besonders, dass der Elefant seine Fang-Methoden selbst mitzubringen hat. Die Zuständigkeit über die Daten sind mit OOP hart geregelt, denn die Daten einer Klasse können (unter Vorraussetzung man macht alles privat) nur von ihren Methoden verändert werden.

Was genau möchtest du mit dem Link sagen? Dass der Elefant die Fang-Methode selber mitbringen muss ist dort völlig ironisch gemeint. Die Zugehörigkeit von Daten ist im weiten Sinne geregelt, das gilt aber längst nicht für Funktionen – und dass einige Sprachen es erzwingen wollen, ist ein fundamentaler Fehler. Insbesondere Funktionen, die mehrere Objekte (möglicherweise sogar unterschiedlichen Typs) vollkommen gleichwertig behandeln und herumschieben, haben in Pseudo-Objekten, in die man sie static reinzwingt, damit der Compiler Ruhe gibt, nichts verloren (siehe: jede Mathebibliothek). Noch dazu gehören selbst Funktionen, die klar ein Objekt verändern, oft genug nicht in Klassen gestopft (nicht-C++ler können bei Interfaces and Packaging aufhören, zu lesen).

Frage ist wie sieht die Engine aus dem Eingangspost denn im Moment aus?

Öh... was soll ich darauf sagen?

Ob die Engine bereits stabil läuft, oder ob du noch am Anfang stehst. Ob du mit dem bisherigen Vorgehen bei der Programmierung zufrieden bist, oder ob du dir wünschst, alles anders gemacht zu haben. Ob alles weitestgehend fehlerfrei funktioniert, oder ob jeden Tag ein neuer haarsträubender Bug auftaucht. Ob du noch den kompletten Durchblick hast, oder bereits den Verstand verlierst. Usw …

[eXile]

Noch dazu gehören selbst Funktionen, die klar ein Objekt verändern, oft genug nicht in Klassen gestopft (nicht-C++ler können bei Interfaces and Packaging aufhören, zu lesen).

Endlich sagt es mal einer! Oh Gott, was ich schon für einen Kampf gegen Windmühlen deswegen gefochten habe. Genau dafür wurden doch eigentlich Namespaces eingeführt. Ich selber stelle mir häufig an solchen Stellen die ganz einfache Frage "Wieviele Zeilen Code müsste ich ändern, wenn sich hier die interne Struktur verändert?". Damit bin ich bisher auch immer gut gefahren :)