Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 13:33

Foren-Übersicht » DGL » Umfragen
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 51 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4  Nächste

Mit welcher Programmiersprache programmiert ihr am liebsten?
Umfrage endete am Do Apr 02, 2009 22:01
Pascal (Delphi, OOP) 60%  60%  [ 25 ]
C/C++ 17%  17%  [ 7 ]
C# 12%  12%  [ 5 ]
Java 12%  12%  [ 5 ]
Python 0%  0%  [ 0 ]
(Visual) Basic 0%  0%  [ 0 ]
Was exotisches. 0%  0%  [ 0 ]
Abstimmungen insgesamt : 42
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 30, 2008 20:11 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mär 30, 2007 18:35
Beiträge: 331
Wird nicht weiterentwickelt? Interessant. http://en.wikipedia.org/wiki/C%2B%2B0x

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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 30, 2008 20:36 
Offline
DGL Member

Registriert: Sa Aug 09, 2008 09:07
Beiträge: 112
Pellaeon hat geschrieben:
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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 30, 2008 21:06 
Offline
DGL Member
Benutzeravatar

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. :wink:
Ich hoffe doch mal nicht, dass es bzgl Restless Exporter ein Memleak gibt, zur not nicht zu oft exportieren. :lol:

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 30, 2008 21:32 
Offline
DGL Member

Registriert: Sa Nov 29, 2008 22:31
Beiträge: 18
Java ist nur schlechtes C++. Hab ich mal irgendwo gelesen. :lol:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 10:28 
Offline
DGL Member
Benutzeravatar

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 13:15 
Offline
Guitar Hero
Benutzeravatar

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 13:28 
Offline
DGL Member

Registriert: Sa Aug 09, 2008 09:07
Beiträge: 112
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:
Code:
  1. void foo(...) = 0;

(glaub das stimmt so...)

Edit:
http://tutorial.schornboeck.net/pure_virtual.htm


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 14:28 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Apr 25, 2005 17:51
Beiträge: 464
Zitat:
>> 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 14:39 
Offline
DGL Member

Registriert: Sa Aug 09, 2008 09:07
Beiträge: 112
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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 16:46 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Apr 25, 2005 17:51
Beiträge: 464
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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 31, 2008 18:11 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
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 ^^)

Aya


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jan 01, 2009 02:24 
Offline
Guitar Hero
Benutzeravatar

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jan 01, 2009 03:59 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Flash hat geschrieben:
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.

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jan 01, 2009 11:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo Flash,

mit Interfaces kann man glaub ich nur Mehrfachvererbung von Methoden umgehen, aber wie sieht es mit der Vererbung von Attributen aus?

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jan 01, 2009 12:41 
Offline
DGL Member
Benutzeravatar

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

_________________
http://3das.noeska.com - create adventure games without programming


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 51 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4  Nächste
Foren-Übersicht » DGL » Umfragen


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 12 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.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.054s | 18 Queries | GZIP : On ]