spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Theprogrammer"«

EIn Programm ist objektorientiert oder ein Programm ist nicht objektorientiert. Wenn man da jetzt wie wild prozedural und objektorientiert durcheinander wirft ist das für mich nicht objektorientiert.

Es gibt auch noch andere Programmierparadigmen ausser prozedural und objektorientiert, und ja die beiden sollte man nicht gerade mischen. Ein Großteil der Sprachen erlaubt es im Grunde auch nicht, C++ ist dabei mit wenigen anderen eine Ausnahme (ich glaub in der neusten Ada Version gab es auch zusätzlich Objektorientierung)

Ich finde C# erleichtert Spieleprogrammierung, die meisten Pattern in C++ einzuhacken ist einfach nur ein Krampf. Sicher eght das alles mit einem einigermaßen ordentlichen Memory Management System oder SmartPolinter oder sonst welchen ähnlichen Tools.
Bedingt durch den Fakt, das es in C++ nur virutelle und rein virtuelle Methoden gibt, kein direktes Schlüsselwort abstract oder interface macht OOP mit C++ für mich nicht wirklich Spaß.

C++ wurde einfach nicht für Objektorientierung gedacht, es wurde als Weiterentwicklung zu C gesehen und nicht als neuer Ansatz.

C# und Java unterstützen OOP wesentlich besser und große Spiele brauchen heutzutage immer mehr die Objektorientierung.

Zitat

Bedingt durch den Fakt, das es in C++ nur virutelle und rein virtuelle Methoden gibt, kein direktes Schlüsselwort abstract oder interface macht OOP mit C++ für mich nicht wirklich Spaß.

In JAVA und C# ist ein Interface im Grunde doch nur eine Klasse bei der alle Methoden virtuell sind? Man muss alle Methoden überschreiben. Das ist genau das gleiche, wie wenn man in C++ alle Methoden als virtual deklariert!

Zitat

Es gibt auch noch andere Programmierparadigmen ausser prozedural und objektorientiert, und ja die beiden sollte man nicht gerade mischen.

Das ist mir durchaus bewusst

Zitat

die meisten Pattern in C++ einzuhacken ist einfach nur ein Krampf.

Du kennst mit ziemlicher Sicherheit mehr Patterns als ich aber die, welche ich kenne lassen sich in C++ und C# nahezu identisch implementieren.
Z.b. Observer, Adapter, Strategy, Singleton, ...

Ich mag C# auch aber ich sehe nicht, dass es viel komfortabler bei OOP ist. Das meiste Zeit sparen bei meinen Programmen in C# gegenüber den äquivalenten Gegenstücken in C++ kommt von der automatischen Speicherverwaltung und dem Datenbank und Fenstereditor oO

@R3sident3vil:

eher ist .Net ein Java-Pendant, Java gabs früher
Und die Java Runtime ist sicher eine Platform! Deswegen finde ich dass genaugenommen C / C++ platform-unabhängiger ist als Java. Für C/C++ gibts für fast jede Platform einen Compiler. Die Libs sind es meistens nicht, aber bei C++ gehören die auch nicht zum Sprachstandard im Gegensatz zu Java.


@koschka:
Was findest Du an Interfaces besser als an Klassen ?
Das Problem, das bei Mehrfachvererbung immer aneschwärzt wird, (Namenskonflikte) hat man bei Interfaces ja genau gleich!
Statt Abstract einfach nur virtuelle Methoden erstellen ohne sie zu implementieren, dass geht glaub ich...

Und C++ wurde für mehrere Paradigmen konzipiert, darunter auch objektorientiert und prozudeal.

Ich persönlich schätze die Freiheit in C++ für den Programmierer sehr, ich kann so abstrakt- oder maschinen-nah, prozudeal oder objektorientiert und so schön/unschön programmieren wie ich möchte und wie es meinem Stil entspricht.
Bei C# und noch mehr bei Java ist man extrem eingeengt, und durch das Fehlen des Präprozessors entgeht viel Flexibilität.

Zugegeben, einige Templates sind in C++ mühsam zu implementieren (Singletons als einfaches Beispiel :roll: ), solches Zeug wird mit der nächsten Version aber verbessert.

Java und C# sind ein Vorteil wenn man kurze Entwicklungszeit haben will, was bei 08/15-Anwendungen der Fall ist, sich entsprechend aber auch auf die effizienz auswirkt.

Zitat von »"Beneroth"«

Das Problem, das bei Mehrfachvererbung immer aneschwärzt wird, (Namenskonflikte)

Was hat das eine mit dem anderen zu tun??

Zitat von »"Beneroth"«

hat man bei Interfaces ja genau gleich!
Statt Abstract einfach nur virtuelle Methoden erstellen ohne sie zu implementieren, dass geht glaub ich...

Das geht in der Tat... Aber bei C# wird nochmal unterschieden zwischen abstrakter Klasse und Interface!

Zitat von »"Beneroth"«

Und C++ wurde für mehrere Paradigmen konzipiert, darunter auch objektorientiert und prozudeal.

Was anderes wurde hier auch garnicht behauptet, nicht?

Zitat von »"Beneroth"«

Ich persönlich schätze die Freiheit in C++ für den Programmierer sehr, ich kann so abstrakt- oder maschinen-nah, prozudeal oder objektorientiert und so schön/unschön programmieren wie ich möchte und wie es meinem Stil entspricht.

Die Frage ist, braucht man das alles tatsächlich?

Zitat von »"Beneroth"«

Bei C# und noch mehr bei Java ist man extrem eingeengt, und durch das Fehlen des Präprozessors entgeht viel Flexibilität.

Der Präprozessor ist auch bei C# erhalten geblieben! Nur nicht so verunstaltend-fähig wie bei C++.

Zitat von »"Beneroth"«

Zugegeben, einige Templates sind in C++ mühsam zu implementieren (Singletons als einfaches Beispiel :roll: ), solches Zeug wird mit der nächsten Version aber verbessert.

Bei C# gibts garkeine richtigen Templates. C# kennt dafür richtige "Generics" (im Gegenteil zu C++)! Und beides hat mehr schlecht als recht was mit Pattern (was du wohl meinst) zu tun!

Zitat von »"Beneroth"«

Java und C# sind ein Vorteil wenn man kurze Entwicklungszeit haben will, was bei 08/15-Anwendungen der Fall ist, sich entsprechend aber auch auf die effizienz auswirkt.

Wieso sehen alle immer nur die "kurzen Entwicklungszeiten" als Vorteil?

Zitat von »"Beneroth"«

Was findest Du an Interfaces besser als an Klassen ?

o Bei den meisten Sprachen Mehrfachvererbung möglich
o Sehr wichtig für nahezu alle Design Pattern
o Wichtig für Adapter, "Achitectual Glue" von verscheidenen Frameworks, Extensibility von Frameworks
o ermöglicht Komponentendesign (austauschbar)
o ermöglicht "good smell design"

Sicher sind manche Punkte eher subjektiv, aber jeder hat glaube ich seine Daseinsberechtigung und Interfaces sind extrem wichtig in der Softwaretechnik.

Zitat von »"Abrexxes"«

Wieso sehen alle immer nur die "kurzen Entwicklungszeiten" als Vorteil?

Viele Vorteile die als Werbespruch taugen hat C# nun mal nicht, letztendlich ist es auch nur ein Framework das Kompromisse macht und daher mehr Power verbraten muss was in einigen Anwendungsgebieten nun mal tabu ist.

Abrexxes korrekt, aber hier gehts um Anfänger die Spiele >mal schnell< schreiben wollen, dazu ist meiner Meinung nun mal mehr C# geeignet, oder zumindest besser geeigent als viele hier tuen.

Zitat von »"Beneroth"«

Das Problem, das bei Mehrfachvererbung immer aneschwärzt wird, (Namenskonflikte)

Das Problem heist Diamantenproblem und ja, Mehrfachvererbung ist etwas tolles, ich weis nicht warum das aktuelle OOP Sprachen nicht benutzen man kann damit tolle Sachen wie Fassetten bauen und einiges an mehr Objektorientiertheit bringen.

Zitat von »"Theprogrammer"«

Zitat

Bedingt durch den Fakt, das es in C++ nur virutelle und rein virtuelle Methoden gibt, kein direktes Schlüsselwort abstract oder interface macht OOP mit C++ für mich nicht wirklich Spaß.

In JAVA und C# ist ein Interface im Grunde doch nur eine Klasse bei der alle Methoden virtuell sind? Man muss alle Methoden überschreiben. Das ist genau das gleiche, wie wenn man in C++ alle Methoden als virtual deklariert!

Richtig, aber sowas hat mit Lesbarkeit von Code zu tun und diese Methode mit dem virtual in C++ ist nun wirklich nicht schön und Interfaces sind auch nicht auf einen Blick ersichtlich. Ja ich weiss, man kann das mit Makros mühsam hinzuprogrammieren aber sowas ist hässlich.

Zitat von »"Theprogrammer"«

Zitat

die meisten Pattern in C++ einzuhacken ist einfach nur ein Krampf.

Du kennst mit ziemlicher Sicherheit mehr Patterns als ich aber die, welche ich kenne lassen sich in C++ und C# nahezu identisch implementieren.
Z.b. Observer, Adapter, Strategy, Singleton, ...

Dann zeig mir mal bitte wie du eine Factory Pattern programmierst ohne den Speicher vollzumüllen ohne Memory Management. Bei allen Patttern gilt, dass man mit dem new Operator immer in Konflikte kommt wenn man sauber programmieren will. Sicher ist das eher eine Eigenschaft von C++ das man den Speicher selbst verwalten muss, als ein Problem aber es ist nicht schön. Genauso unschön wie die fehlenden Schlüsselwörter interface und abstract - brsonders für Anfänger und Hardcore Design Pattern Benutzer.

Zitat von »"Theprogrammer"«

Ich mag C# auch aber ich sehe nicht, dass es viel komfortabler bei OOP ist. Das meiste Zeit sparen bei meinen Programmen in C# gegenüber den äquivalenten Gegenstücken in C++ kommt von der automatischen Speicherverwaltung und dem Datenbank und Fenstereditor oO

Ich weis ja nicht wie du mit C++ programmierst, aber die Funktionalität und den Fenstereditor hab ich da auch und darum geht es auch nicht :roll:

In C# hat man einfach ein riesiges Framework darüberliegen, was durchaus Einsteigern das Leben leichter macht um auf das Thema zurückzukommen, und ja man kann es durchaus auch für Spiele einsetzen. Mit etwas Interesse an der ganzen Sache sogar für recht komplexe Spiele. Trotzdem mindert das nicht Existenzwürdigkeit von C++.

Zitat von »"David_pb"«

Wieso sehen alle immer nur die "kurzen Entwicklungszeiten" als Vorteil?

Time To Market :roll:

Ist zumindest nach meiner Erfahrung ein Liebelingswort bei gewissen Softwareherstellern :?

Zitat von »"Koschka"«

Es wäre nett wenn du mir einschlägige Referenzwerke nennen könntest, ich glaub nicht alles was irgendwo bei google rumgeistert.

also man findet in fast allen spieleprogrammierforen, diese aussage, und wenn dir das nicht reicht, dann interpretiere doch bitte folgendes:

http://www.microsoft.com/germany/msdn/co…default.mspx#d2

es wird also nicht mehr weiterentwickelt, also im prinzip von xna abgelöst

Zitat von »"TrommlBomml"«

es wird also nicht mehr weiterentwickelt, also im prinzip von xna abgelöst

Zitat von »"MSDN"«

Das XNA Framework wird über ein Managed-API verfügen, um mit Hardware für die Xbox 360 und Windows zu funktionieren. Dieses API umfasst die Funktionalitäten, die zuvor in der MDX 2.0 Betaversion enthalten waren.

Vielen Dank für den Link, für mich heist das nur das es anderes genannt wird... wo ist den jetzt das Problem?Vom einstellen sehe ich da nichts.

jo, du hast schon recht. aba an sich das managed directx wird so nich weiterentwickelt. es dient ja als api für xna. ich würde das ungefähr so vergleichen wie das integrieren von directdraw in direct3d zu directx graphics. directdraw wird ja nicht weiterentwickelt und ist veraltet.