Was sollte Crysis in Java bringen? DirectX gibts nicht für Java und es gibt nicht viele Spieleentwickler, die auf OpenGL setzen.
Das Problem mit dem GC wurde schon angesprochen, aber auch der Speicherverbrauch würde durch Java um einiges steigen. Ok, es gibt jetzt 64 bit Systeme,
aber ein Spieleentwickler kann es sich nicht leisten, alle mit 32bit Rechnern/Betriebssystemen zu übergehen. Über Konsolen brauchen wir garnicht reden.
Außerdem wird sich Crytek nicht hinsetzen und ihren Bestandscode auf Java portieren, den gibts halt schon für C++.
Ein Crysis in Java würde aber sicher nicht schneller sein, sondern langsamer.
Ach ja und Mehrfachvererbung ist ein sinnvolles Feature, wenn man es richtig anwendet. Wer immer diese Diamantstruktur programmiert, ist selber schuld ...
Wenn du mir ein vernüftiges Beispiel für Mehrfachvererbung nennen kannst, nehm ich das sofort wieder zurück.
Ich finde C++ schon cool und wie gesagt habe ich es auch schon verwendet, aber Java bietet eine riesige Lib in der schon alles implementiert ist was man ab und zu braucht.
>> Kennst du da ein paar Templates wie man den Code aufbaun könnte?
Kennst du da was?
Edit:
Du musst mich verstehen... ich stehe wieder einmal und weiß nicht was ich jetzt nehmen soll bzw. was ich will.
C++ würde mir wirklich gefallen, aber bei 0 beginnen ist hart und macht anfangs nicht wirklich viel Spaß
@Markus
Bis auf den 1. Absatz schreibst du an meinem Post vorbei. Ich habe nie etwas der Gleichen behauptet.
Registriert: Mo Jan 31, 2005 11:02 Beiträge: 432 Wohnort: Rheinlandpfalz
Lord Horazont hat geschrieben:
@MatReno: Ja, das mit dem Aufräumen sehe ich genauso. Wobei, hat Python nicht auch nur einen GC? Oder gibts da in Restless ein riesiges Memleak? Oder liegen die Objekte aufm Stack und werden dann automatisch freigegeben?
Mhh... ja, du könntest recht haben... GarbageCollector... wobei der GC optional ist, denn die __del__ Anweisung eines Objektes wird dann ausgeführt, wenn keine Referenz mehr zu diesem Objekt existiert, und die gibt dieses dann frei.
Aber das macht jetzt Python nicht weniger schön für mich. Als primäre Scriptsprache ist das ok.
Ich hoffe doch mal nicht, dass es bzgl Restless Exporter ein Memleak gibt, zur not nicht zu oft exportieren.
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo Andreas,
ich hatte mal eine Situation, wo mir Mehrfachvererbung ganz nützlich war :
Es gab eine Klasse für einen Spielstein ( Stone ), die die ( logische ) Farbe und Position des Steins auf dem Brett beinhaltete ( ich hatte es versucht möglichst abstrakt zu halten, um es später für eine eventuelle KI zu verwenden ).
Dann hatte ich noch eine Klasse Stone3D, die die Eigenschaften von Stone und des Modells eines Rotationskörpers ( RotModel ) erben sollte.
In diesem Fall war es dann beim Rendern des Steines ganz praktisch auf die Memberdaten beider Basisklassen zuzugreifen.
Viele Grüße
dj3hut1
_________________ Wenn Gauß heute lebte, wäre er ein Hacker. Peter Sarnak, Professor an der Princeton University
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Das ist genau ein Beispiel für den Nutzen von Interfaces.
Im Endeffekt dienen Interfaces und Mehrfachvererbung genau dem selben Zweck.
Gibt es in C++ auch interfaces? Oder hat man es bei der Mehrfachvererbung belassen?
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Man kann sie mit abstrakten Klassen vergleichen.
Wenn man also etwas derartiges braucht nimmt man eine normale Klasse und die Methoden schauen dann so aus:
>> Kennst du da ein paar Templates wie man den Code aufbaun könnte? Kennst du da was?
Wie meinst du die Frage genau? Design technisch oder Bibliotheken. Als Erweiterung der STL kannst du boost ansehen: http://www.boost.org Viele Teile der Lib sind auch durch den TR1 und TR2 Bestandteil für C++0x geworden und werden in einigen Compilern schon unterstützt. Ansonsten einfach boost rauf und gut. Das Ding is riesig.
_________________ __________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup
Design-Technisch...
Mir fehlt der Ansatz mit Header und Source-Datei umzugehen.
Wenn man etwas importiert, dann will man ja nur den Header importieren.
In dem stehen dann eig. nur deklarationen und im Source (.cpp) stehen dann die definitionen.
Oder liege ich da falsch?
In Java gibts ja da nur ein Konzept und auf das baut die ganze Sprache auf.
Aber wie könnte man das in C++ machen?
Ein Konzept braucht man ja, sonnst wirds unleserlich und unlogisch.
Grundlegend gilt die Trennung zwischen Schnittstelle und Implementierung. Schnittstellen in die Headerdateien und Implementierung in die cpp-Datei. Du liegst also richtig. Ausnahmen sind inline-Funnktionen und Templates. Dort muss beides in der Headerdatei liegen. Es darf aber quellcodetechnisch trotzdem in Deklaration und Definition geteilt werden, wenn man das möchte.
Ist also vergleichbar in Pascal mit den Interface und Implementation-Teil. (nicht 100%, aber von der Vorstellung her)
_________________ __________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup
Zu den Interface / Mehrfachvererbungen... korrigiert mich wenn ich falsch liege, aber soweit ich weiß sind Interfaces nur deklarationen, keine definitionen..
Wenn im Interface z.B. eine funktion "doSomething" deklariert ist und ich etwas von dem interface ableite, dann muß ich die definition von doSomething in meiner klasse implementieren.
Sprich wenn ich 20 klassen habe die vom interface abgeleitet sind, hab ich u.U. 20x den selben code in jeder klasse stehen.. oder liege ich da falsch?
Bei Mehrfachvererbung hingegen definiere ich eine klasse ganz normal mit definition und deklarationen und kann nun einfach von 2+ klassen ableiten und alles nutzen was die auch können, ohne eine zeile code in meiner eigentlichen klasse zu ändern.
Ein beispiel wo ich das vermehrt eingesetzt habe ist bei meiner UI:
Ich habe verschiedene componenten, Button, Panel, Edit etc die je nachdem nen Rahmen, ne Caption etc haben.
Am beispiel vom Rahmen gäbe es jetzt 4 möglichkeiten das zu realisieren:
1) Den rahmen einfach in jeder Componente via copy/paste implementieren, sprich jede componente hätte eine setBorder(), setBorderWidth(), setBorderColor() etc funktion mit den dazugehörigen variablen und implementationen.... extrem unelegant
2) Man erstellt eine Klasse TBorder und gibt dieser die ganzen funktionen. In den einzelnen Componenten erstellt man dann nurnoch eine instanz von TBorder und kann dann via border.setWidth() etc drauf zugreifen. Geht, finde ich aber auch nicht so optimal..
3) Man leitet jede komponente zusätzlich via Mehrfachvererbung noch von TBorder ab, dann hat die eigene klasse automatisch auch die z.B. setBorderColor() funktion ohne das man auch nur eine weiter zeile code schreiben muß um irgendwas zu implemetieren.
4) Man kann es machen wie die VCL und alles mit extrem vielen ableitungen machen.. vonwegen TBaseUI, TBorderedUI, etc.. allerdings hat man dann oftmals bei komponenten die über die standard controls wie edit etc hinausgehen das problem das man aufeinmal nen Border hat obwohl die komponente den nicht braucht..
Ich hab mich für die 3te lösung entschieden... wenn ich jetzt eine neue Komponente erstelle, z.B. nen Button leite ich den einfach von den jeweiligen Base-Klassen ab, das sind in meinem Fall "BaseUI, BorderedUI und CaptionUI".
Dasselbe mit Interfaces ginge nicht, denn da würde ja nur die deklaration von setBorder(), setBorderColor() etc übernommen werden, die definition müßte man selbst implementieren da das ja im interface nicht geht. (Wie gesagt, falls ich hier falsch liege sagt es ^^)
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Du hast da im Grunde genommen recht. Allerdings wenn du 20 Klassen hast bei denen ein Interface implementiert werden soll, besteht zwischen denen meistens auch Abhängigkeiten. Z.B. kannst du dann eine Basisklasse erstellen, welche mehrere Interfaces abstract implementiert und von der dann die 20 Klassen erben.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Du hast da im Grunde genommen recht. Allerdings wenn du 20 Klassen hast bei denen ein Interface implementiert werden soll, besteht zwischen denen meistens auch Abhängigkeiten. Z.B. kannst du dann eine Basisklasse erstellen, welche mehrere Interfaces abstract implementiert und von der dann die 20 Klassen erben.
Ja natürlich, das war jetzt auch als beispiel gedacht
Gehen tut immer alles irgendwie, das steht ausser frage... aber ich finde Mehrfachableitung kann manchmal halt echt praktisch sein, bzw komfortabel.
Und es ist ja nicht so als würde es etwas wie interfaces in C++ nicht geben, das wären dann nämlich einfach Abstrakte-Klassen die via Mehrfachvererbung mitgegeben werden.
Registriert: Di Jul 01, 2003 18:59 Beiträge: 887 Wohnort: (The Netherlands)
Programmiersprache: fpc/delphi/java/c#
I learned most of oop programming through the books on: http://fundamentenoop.digibel.be/ unfortunately they are only in dutch.
There are versions for delphi, c++ and java. You see the similarities and differences between the languages by comparing the books.
I have the delphi and c++ one.
Interfaces in delphi can only handle methods and not properties or variables i believe.
The questions is are interfaces needed in delphi. I think not. Most often the complicate things in delphi where they make your live easier in c#. The other way around the solution in delphi without interfaces does not work as nicely in c#.
Mitglieder in diesem Forum: 0 Mitglieder und 20 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.