Die besten Programme enthalten keine Klassen!?

RHBaum

Ich denke aber doch, dass man gerade in der Spieleprogrammierung viel von Klassen profitiert.

Naja, ich denk mal eher das gerade spiele von den vorteilen einer OOP am wenigsten profitieren, in der Praxis ! Zumindest sinds die, die am wenigsten drauf angewiesen sind !

Schaut euch doch mal die Spiele aufm markt an ... es ist die einzige Branche wo man sehr viel Geld ausgeben muss, um AlphaTester zu werden ! Wenn Software firmen SW mit diesen QUalitaetsstaenden an Kunden verkaufen wuerden, dann wuerde die SW firma ihre Mitarbeiter nimmer bezahlen koennen, weil das komplette Geld fuer die Anwaelte draufgeht !
Der Komplette Entwicklungsprozess unterscheidet sich doch auch von anderen Projekten. Meist hat nen Designer Ideen, dannn wird programmiert, und die ideen werden soweit umgesetzt wie man ahnung und material zu hat. In der Zwischenzeit vergroessert sich das team, andere ideen kommen hinzu, und ploetzlich geht alles in eine komplett andere richtung. Das ist nen unendlich rekursiver prozess, bis das Projektmanagment sagt Stop!, wir brauchen Geld. Dann geht das Spiel Gold, obwohl es nicht mal Alpha Status hat
Denk mal das ist keine gute Grundlage fuer OOP und saueberes Design.
Ne Spielentwicklung mit richtigen Lastenheft und so kann ich mir einfach ned vorstellen, zumindest wenn ich mir die SPiele anschau ...

Ciao ...

Artchi

Aha, du kannst dir also kein Lastenheft (in der Spieleindustrie "Designdoc" genannt) vorstellen? Sorry, aber du irrst dich gewaltig! Ohne Lastenheft brauchste bei einem Publisher erst garnicht ins Büro! Da kann die Grafik noch so spektakulär sein. Und Spiele profitieren sehr wohl von OO, habe selbst an der Dreamcast-Portierung von Ubisofts "Heroes of Might & Magic III" mitgewirkt, und das ganze PC-Spiel war reines OO-Design. Und das Spiel ist schon älteren Datums und ein Top10-Verkaufshit weltweit. Heute dürften wohl die wenigsten Games Nicht-OO sein. Und ja, Ubisoft und 3DO/NewWorldComputing wollten, bevor sie uns loslegen liessen, ein Designdoc für das Portierungsvorhaben haben von uns haben. Alleine für eine Portierung, nicht mal eine Neuentwicklung wohlgemerkt, war ein Lastenheft nötig!

Soviel zu deiner Theorie die total Praxisfern ist.

Bashar

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++.

Glaub ich nicht. John Carmack ist ein verdammt helles Köpfchen Er ist auf C++ umgestiegen, als er erstmals noch andere Leute an dem Programm rumcoden lassen hat. C++ macht es ein wenig leichter, Schnittstellen zu definieren und deren Einhaltung durchzusetzen. Ich wette, dass der Code an sich immer noch hauptsächlich C-Style ist.

RHBaum

@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.

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 ?

Und nein, gibt ja nicht nur schwarze Schafe. Aber leider werden es immer mehr ... bzw. wird es zur Gewohnheit. Ist aber sicher ned nur Sache des SW Designs. Aber Fakt ist, das grad zuvaerlaessigkeit und Erweiterbarkeit und Fehlerfreiheit am meisten von OOP profitieren. Alles sachen wo sich die SpieleIndustrie meist ned so mit Ruhm bekleckert ...

Heute dürften wohl die wenigsten Games Nicht-OO sein

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 ...

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.