Die besten Programme enthalten keine Klassen!?

Shade Of Mine

otze schrieb:

auch wenn man mich jetzt steinigen wird: oop ist ein bischen langsamer als prozedurale programmierung.
das liegt einfach an den bei anständiger programmierung sehr verschachtelten klassen,aber es ist wirklich nicht sehr viel, weil die compiler inzwischen sehr gut optimieren.

jo, ich steinige dich.

Hast du eine Begründung warum OOP langsamer sein soll?
C++ Programme können zB schneller als C Programme sein, ohne dass man besonders zaubern muss.

otze

ok, ich versuchs mal an einem ganz kurzen codestückchen deutlich zu machen

int addition(int&,int&);//function zum addieren 2er werte
int komplexe_berechnung(int& a,int& b){
    //ganz komplexe berechnung
    return addition(ergebnis1,ergebnis2);
}
class math{
    public:
        int addition(int&,int&);//methode zum addieren 2er werte
};
class irgendeine{
    private:
        math mathe;
    public:
        int komplexe_berechnung(int& a,int& b){
            //ganz komplexe berechnung
            return mathe.addition(ergebnis1,ergebnis2);//erst erfolgt ein memberzugriff, dann wird von dem member die funktion aufgerufen, ergo langsamer       
        }    
};

Helium

Dafür gibt's ein dickes LOL.

Das was du da machst ist nicht OO, aber darum ging es. Du baust einfach irgendwie künstlich ein wenig Overhead ein. Du kannst auch eine Warteschleife einsetzen oder ähnliches und dann sagen, das die Version mit Warteschleife langsamer ist.

Bashar

otze: Dein Beispiel spricht eher dafür, dass du so einiges in der OOP noch nicht verstanden hast. Zuerst mal zur technischen Seite: Die Klasse mathe hat keine Members, die von addition benutzt werden könnten, also kann addition auch gut static deklariert werden. Dann wird der Aufruf vom Compiler genauso übersetzt wie ein normaler Funktionsaufruf. Was auch nicht weiter verwundert, weil du den Code überhaupt nicht von prozedural nach OO umgeformt hast. Er ist weiterhin prozedural, was nur durch die Klasse mathe ein wenig verschleiert wird.

Ich will jetzt nicht im Detail beschreiben, wie nicht-statische Methode und virtuelle Funktionen sich in C umschreiben lassen (in OOP für Dummies gibts ein Kapitel dazu) Fakt ist, dass OOP in der Theorie genauso schnell ist wie prozedurale Programmierung. Praktische Unterschiede ergeben sich -- von eventuell unterschiedlich gut optimierenden Compilern mal abgesehen -- aus der unterschiedlichen Herangehensweise, die in unterschiedlichen Designs resultiert.

Speziell C++ hat gegenüber C sogar theoretisch die Oberhand. Statischer Polymorphismus (Templates) wird in C entweder überhaupt nicht, mühsam und fehleranfällig durch Makros, oder mit dynamischen Mitteln nachgebildet.

groovemaster

@otze
Dein Beispiel ist keinesfalls repräsentativ. Sicherlich muss bei Klassen der this Zeiger "durchgeschleust" werden wenn man auf Member zugreift. Aber das sind höchstens 1 oder 2 Instruktionen für den Prozessor. Und das muss nicht langsamer sein. Offenbar hast du noch nie was von parallel arbeitenden Instruction-Pipelines gehört.

RHBaum

Speziell C++ hat gegenüber C sogar theoretisch die Oberhand. Statischer Polymorphismus (Templates) wird in C entweder überhaupt nicht, mühsam und fehleranfällig durch Makros, oder mit dynamischen Mitteln nachgebildet.

Und ich behaupte immer noch, das C++ kein GeschwindigkeitsVorteil an sich bring !!!
Wenn ich unter C die selben Tricks verwenden darf, wie C++ intern es tut (internes asm), bin ich unter C mindestens genau so schnell. Nur unter C++ siehts eben schoener und eleganter aus, und ist ned halb so lang -> viel besser wartbar.

Das Problem des Vorurteils, das OOP langsamer sein als procedural ist halt, das man mit OOP lernt zu abstrahieren, nicht mehr so sehr problemnah arbeitet. die Klassen generischer werden, und lieber wiederverwendet (mit overhaed) wird als neu zu implementieren. Was ja eigentlich auch nen Vorteil ist.
Aber wenn man das meidet, kann man schon sehr schnell sein ...
In C gruebelt keiner wegen VTables und Overhaed bei dynamischer Polymorphie, auch RTI ist da kein Thema.
Aber in C++ nimmt man es meist als gegeben hin ... Ist aber eher nen Problem des Designs.
Und mit Templates tun sich die Leute halt schwer, ist auch ned so ohne ...

Ciao ...

otze

das ziel des beispiels war nur, den overhead beim zugriff auf die members zu zeigen, nicht mehr, ich weis wie oop funktioniert, aber andererseits hatte ich keine lust, jeweils 50 zeilen code für prozedurale/oop programmierung zu schreiben.

aber wenn ihr wollt, kann ich ja hier mal ein richtiges oop beispiel anhängen, das wäre dann wesentlich länger und der groschen würde wesentlich langsamer bei euch fallen.

achja, was mich auch wundert ist,dass ihr rummmotzt weil ich ne funktion addition so verwirkliche, nicht aber,dass ich überhaupt ne funktion addition benutze,vielleicht war das ja sone art zeichen von mir, dass der code wirklich nur ein absolut dummes beispiel sein soll, was nur eine sache zeigen soll, vielleicht irr ich mich aber auch mit der deutung meines eigenen codes, was solls .
btw, wenn ich sage, dass oop minimal langsamer ist, dann mein ich damit nicht mehr als 2-3 asm befehle,aber sowas häuft sich an.

Helium

Ach

void foo (int a, int b, int c, int d, int e);
{ ... }

vs.

class Foo {
   int a, b, c, d, e;
public:
   Foo (int a, int b, int c, int d, int e);

   void foo ()
   { ... }   
};

Beim Aufruf von foo werden 5 ints kopiert, beim Aufruf von Foo::foo nur ein this-Zeiger.

Bashar

otze schrieb:

das ziel des beispiels war nur, den overhead beim zugriff auf die members zu zeigen, nicht mehr, ich weis wie oop funktioniert, aber andererseits hatte ich keine lust, jeweils 50 zeilen code für prozedurale/oop programmierung zu schreiben.

Ein 50-zeilen-Beispeil kannst du dir trotzdem schenken, das ändert nichts. OOP ist nicht per se langsamer, schon gar nicht aufgrund des Memberzugriffs.

achja, was mich auch wundert ist,dass ihr rummmotzt weil ich ne funktion addition so verwirkliche, nicht aber,dass ich überhaupt ne funktion addition benutze,vielleicht war das ja sone art zeichen von mir, dass der code wirklich nur ein absolut dummes beispiel sein soll, was nur eine sache zeigen soll, vielleicht irr ich mich aber auch mit der deutung meines eigenen codes, was solls .

Es ist schon klar, dass das eine Abstraktion und ein Mini-Beispiel ist. Aber es begründet nicht deine gezogene Schlußfolgerung, weil, wenn die Funktion static gemacht worden wär, der Compiler einen zur prozeduralen Version äquivalenten Code erzeugt hätte. Andererseits, wenn die Funktion zwingend nicht-statisch hätte sein müssen, dann hätte die prozedurale Version ebenfalls mindestens einen zusätzlichen Parameter haben müssen. Wieder äquivalent.

Artchi

RHBaum schrieb:

@Artchi

Ok, bisserl ueberspitzt isses schon.

Unterschied den ich sehe ... Aenderungen(nennen wir es Patches) werden nicht in der Form einkalkuliert wie bei anderen Produkten. Von daher ist die funktionalitaet der SW eher stabil als leicht erweiterbar.

Ohne Lastenheft brauchste bei einem Publisher erst garnicht ins Büro

Sorry, kenn ich mich echt ned so aus, aber ich denk mal den publisher intressiert es weniger, wie modular deine SW ist, welche Ansi-C++ standards eingehalten werden ... Sicher wird etwas von der Technik da auch intressant sein, aber in erster linie denk ich ist es das Spielkonzept. Ob das mit nem Lastenheft vergleichbar ist ... weiss ich ned, glaubs aber ned so wirklich.

Naja, welchen Kunden interessieren schon die ganz tiefen Details? Wir arbeiten hier an einer Applikation zur Konstruktionsänderung für einen Wolfsburger Konzern. In unserem Lastenheft taucht selbstverständlich nirgends eine Klasse auf. Es steht einfach nur drin, welche Technik und Famework zum Einsatz kommen (analog bei Games die GameEngines etc.). Und dann halt, wie in ein GameDesignDoc, wie der User arbeiten soll, was er für Dialoge sieht usw. (analog bei Games das Gameplay).

Ein Game-Publisher ist ein Kunde, und der will nicht sein Geld investieren, ohne vorher Papier vom Entwickler zu sehen. Warum? Weil es meistens ein Werksvertrag ist, d.h. im Designdoc wird das "Werk" schriftlich definiert. Damit es bei der Bezahlung am Ende keinen Streit gibt. Die Gamesbranche ist eine ernsthafte und ziemlich harte Branche. Viele stellen sich darunter lessiges Freaking vor, ist es aber nicht. Bei der Firma, die ich gearbeitet habe, ist mittlerweile pleite.

Ubisoft und 3DO/NewWorldComputing wollten, bevor sie uns loslegen liessen, ein Designdoc für das Portierungsvorhaben haben von uns haben.

Ubisoft? kann das sein, das das von mal zu mal unterschiedlich gehandhabt wird ?

Ubisoft war glaub ich nur für Europa der Publisher. Ich weiß es jetzt auch nicht mehr so genau. Mittlerweile hat Ubisoft aber nach der 3DO-Pleite aber eh die Rechte an der Serie gekauft.

Glaub ich auch, nen Game mit zig Mille programmcode als proceduralen Code ist sicher ned gut handelbar.
Trotzdem wird C++ meiner meinung nach noch viel zu viel gemieden. Ob in der realen Spieleprogrammierung weiss ich ned, aber in vielen angeblich tollen Buechern ueber 3Design, 3D Spieleprogrammierung, DirectX (ohja, ne MS COM Schnittstelle ! ) wird fuer meinen geschmack viel zu viel in C gecoded, das gaenge mit C++ eleganter und fast genau so schnell ...

Ciao ...

Ja, weil doch viele Bücher veraltet sind. Um C++ kommt man heute einfach nicht rum.

Shade Of Mine

otze schrieb:

btw, wenn ich sage, dass oop minimal langsamer ist, dann mein ich damit nicht mehr als 2-3 asm befehle,aber sowas häuft sich an.

Du musst schon einen Beweis bringen.
Sonst kann ja jeder kommen und irgendwas behaupten.

Raptor

Schwachsinn! Wie alt ist denn das Buch? Ich meine nur, wann wurde es ursprünglich geschrieben? Ich habe hier ein Buch von LaMothe und es ist schon älter (DirectX 5) und er benutzt selber Klassen. Überhaupt sind seine Bücher schon alt.

Ich halte das auch fuer Schwachsinn(falls du jetzt Herrn LaMothe meinst).
Hier das Buch
Es ist 2003(!) erschienen.

Btw: Seite 55 letzer Punkt. "Die besten Programme haben keine Klassen."

MfG

Raptor

energyzer

Definiere: "Die besten Programme"

Was sind die besten Programme?

- Die schnellsten?
- Die schönsten?
- Die praktischten?
- Die am übersichlichsten gecodeteten?
- Die kürzesten?
- ...

Raptor

Hey Mann, bin ich André LaMothe?
Also warum stellst du bitte die Frage an mich???

energyzer

sie ging nicht an dich

war nur allgemein an alle gestellt...

Artchi schrieb:

Lange Zeit hat auch der Quake-Entwickler groß rum getönt, das C++ für Spielecoding ungeeignet ist und er nur C ist geeignet. Warum? Weil er es nicht verstanden hat! Heute codet er aber selber in C++.

Derbster Bullshit den Du da sagst, Carmack auf C++? Würd mal gerne sehen wo Du diesen Schwachsinn her hast! Carmack hat seit Jahren seine Begründung wieso er C benutzt und nicht C++. Achja und er hat auf ner Pressekonferenz selber gesagt: Doom3 und Quake 4 werden in C gecodet.

Was war denn seine Begründung?

speed, er hat mit mehreren Kollegen Tests durchgeführt mit OOP und ohne und der OOP code mit den Klassen, Namespaces und co war ca. 10% langsamer.

Sowas macht er jedes Jahr, gibt es auf gamasutra Artikel drüber.

Artchi

Namespaces und Speedverlust? Haaaaallllooooooooo????????????????? Sorry, wie ich bereits gesagt habe: der Typ VERSTEHT C++ NICHT! Oder hast du dir das gerade ausgedacht? Dann hast Du null Ahnung!

Weiterhin: vielleicht sollte er sich nen vernünftigen Compiler besorgen. Und wer weiß was die als C-Coder gemacht haben? Bei der Parameterübergabe By-Value anstatt By-Reference u.ä.

Mich würde wirklich mal interessieren, ob irgend ein Entwickler, der die Doom3-Engine für 1 Mio. Dollar kauft, sich mit ner C-API abgeben will. Dem würde ich nen Scheibenwischer zeigen, wenn man mir ne 3D-Engine auf den Tisch legen würde, wo ich nur ne C-API bekomme.

@Artchi
zu blöde zum lesen? Ich sagte Klassen und Namespaces, dabei wurden die Klassen auf Herz und Nieren geprüft von mehreren (ca. 15 Leute) darunter auch große C++ bekannte coder! Die Artikel gibt es auf gamasutra. Also bevor du hier so rumflamest wie ein kleines 5 Jähriges Kind dem man den Ballon weggenommen hat, solltest du eher dich mal Informieren was du da für einen Mist laberst.

Und ja ich habe solche Tests auch schon oft mit anderen auf vielen Compilern gemacht und Klassen sind Langsamer als Funktionen aus C.

.NET 7.1 hatte am besten abgeschnitten bei meinen Tests eben so bei Carmacks Test mit den anderen leuten

Wenn du ja sooooo überzeugt bist, dann bau mal ein OOP programm richtig auf C um und teste das mal, dann reden wir weiter.

Und laber net immer einen Mist nach den man dir in den Kopf reingelegt hat sondern lerne mal selbst was zu Testen, ich glaub nämlich nicht das Du es getestet hast sondern laberst nur nach.

Artchi.lame = true;