Was ist am besten geeignet für mich als ehemaliger Delphi-Veteran ?

So wie es aussieht ist Delphi am sterben, Lazarus währe eine Alternative.
C/C++ macht wohl keine Sinn mehr.

Oder währe es am besten auf mit Java und Eclipse umzusteigen. Für Android ist dies wohl die beste Lösung.
Was mich an Java stört, das es keine effizienten Exe-Dateien erzeugt, Java ist angeblich wie ein Interpreter. Oder täusche ich mich da ?

_________________
OpenGL

Nee, das fängt eher wieder an zu leben. Vielleicht zielt Emba nicht mehr so in den Hobby-Bereich, aber sterben ist was anderes.

Die perfekte bzw. die "zeitgemäßeste" Sprache gibt es eigentlich nicht. Grade bei den objektorientierten Sprachen, also Delphi (Object Pascal), C++, Java und Co. spielts, besonders wenn man OpenGL nutzt eigentlich kaum eine Rolle welche Sprache man benutzt. Klar, JAVA wirkt etwas moderner, und an der Delphi-Sprache wird nicht mehr viel erweitert, aber in JAVA kann man rein programmiertechnisch eigentlich nichts machen was in Delphi (evtl. mit anderen Mitteln) nicht auch möglich ist, und vice versa.

Grade bei den aktuell verbreiteten Sprachen kommts eigentlich eher auf den eigenen Geschmack an. Privat nutz ich nur noch Java, v.a. wegen Android (das kostet bei Delphi ja ne ganze Stange Geld), würde dass dann aber grade zusammen mit OpenGL auch für andere Platformen nutzen.

Zum Thema Geschwindigkeit : JAVA ist in diversen Bereichen schneller als Delphi, was u.a. damit zu tun hat das man am Delphicompiler für Win32 kaum noch entwickelt, und den für 64 Bit eh in die Tonne kloppen kann. Der Code wird i.d.R. nicht komplett interpretiert, sondern man nutzt (wie auch in C#) binäre JIT-Kompilate.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

C++11 für denjenigen, der es fast Objektorientiert mag⁽¹⁾, ist definitiv einen Blick wert, C11 für den Prozeduralmasochisten.

FreePascal+Lazarus sollte für einen Delphi-Veteran aber auf jeden Fall erstmal die erste Adresse sein.

grüße,
Horazont

(1): Fragt nicht, ich halte weder C++ noch Java für Objektorientert (virtuelle Konstruktoren anyone?)

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also die perfekte Sprache gibt es einfach nicht.
Bei Computerspielen ist C++ weiterhin die Nummer eins. Und meiner Meinung nach zu recht. Die Sprache ist bloß sehr mächtig und um mit ihr gut entwickeln zu können, muss man wirklich viel lernen, denn es gibt relativ viele Fallen. C++ lässt dem Programmierer einfach viele Freiheiten die ihm zum Verhängnis werden können, wenn er damit nicht umzugehen weiß. Dafür bekommt er eine Sprache die ihm allerdings wirklich viel bietet. Vom Performanceaspekt her, wird guter C++ Code in den aller meisten Fällen schneller als in anderen Sprachen geschriebener Code sein, weil es einfach die besten Compiler gibt und die Sprache unter anderem auf Performance ausgelegt ist. An C++ stören mich auch einige Kleinigkeiten und Altlasten als auch zum Beispiel das veraltete, langsame und komplizierte Include-System. C++11 und auch das kommende C++14 das man allerdings zur Zeit nur auf dem LLVM/Clang-Compiler richtig unterstützt wird, vervollständigen die Sprache mit vielen sinnvollen Konzepten.
Wenn du C++ lernen willst, brauchst du auf jeden Fall Bücher und ein halbes Jahr Übung, bis du "effektiv" guten Code schreiben kannst.

Eine einfachere Lösung die ich noch empfehlen möchte, ist C#. Die Sprache hat leichte Ähnlichkeiten mit den Konzepten von Java, ist jedoch vollständiger und mächtiger ohne so komplex zu sein wie C++. C# wird wie Java JIT kompiliert.

Von Java selbst würde ich persönlich abraten, weil in der Sprache einfach zu viele nicht unwichtige Funktionen wie Value Types, gescheite Generics, vorzeichenlose Integer, Operator Overloading, ... fehlen.
Es ist übrigens schon theoretisch möglich C# oder Java zu nativen Code zu kompilieren, aber absolut unüblich.

Sehr interessant und auf jeden Fall einen Blick wert, ist meiner Meinung nach auch D. Die Sprache ist aus C++, C# und Java hervorgegangen und bietet viele nützlichen Konzepte, ist sehr modern und meiner Meinung nach kaum komplizierter als Java oder C#. Die Sprache wird auch im Gegensatz zu Java oder C# direkt in nativen Code kompiliert. Weil die Sprache allerdings noch so neu ist ist die allgemeine Unterstützung leider noch "stark ausbaufähig".zu C# und Java

@Lord Horazont
Wozu zum Kuckuck sollte es virtuelle Konstruktoren geben? In C++ sollte man ja im Konstruktor nicht mal auf normale virtuelle Funktionen zu greifen, was natürlich schon manchmal etwas blöd sein kann.

Was mich an Lazarus stört, das kleinste Programm braucht über 14MB Speicher.

_________________
OpenGL

Das ist Einstellungssache. Meine .exen sind unter Lazarus kleiner und schneller als mit Delphi. Die .exe von Projekt W z.B. hat mit Lazarus nur knapp 3mb und läuft sogar schneller als das entsprechende Delphi-Kompilat

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Erstmal sollte man wissen, dass C und C++ zwei sehr unterschiedliche Programmiersprachen sind. Dass häufig beide zusammen genannt werden, hat wohl neben historischen Gründen den Grund, dass man in C++ auch C-Libraries benutzen kann und dies auch tut (OpenGL z.B.). Von C würde ich wirklich abraten, da man sehr viel Schreibarbeit (redundanten Code) hat, um wenig zu erreichen.

C++ halte ich - wie man meinem Profil wohl entnehmen kann - für sehr sinnvoll. Wer einmal Templates(C++)/Generics(Java) verstanden und benutzt hat, wird nie wieder in Sprachen wie C programmieren wollen.

Java-Programme werden schon seit einiger Zeit nicht mehr interpretiert, sondern per Just-in-Time-Compiler kurz vor der Ausführung kompiliert. Dadurch sind sie genau so schnell wie andere kompilierende Sprachen. Unter Umständen können sie sogar noch schneller sein, da der Compiler bereits weiß, auf welcher Hardware-Plattform das Programm laufen soll.

Was Java jedoch aus meiner Sicht weniger geeignet für 3D-Anwendungen macht als z.B. C++, sind zwei Dinge:

• Java hat einen Garbage Collector. Dort werden alle reservierten aber nicht mehr gebrauchten Speicherblöcke gespeichert. Von Zeit zu Zeit werden diese Bereiche auf einen Schlag freigegeben. Wann dies geschieht, entscheidet nicht der Programmierer, sondern die Java-VM. Das Löschen kann recht zeitintensiv sein und die weitere Ausführung des Programms verzögern. Eine unregelmäßige Verzögerung des Rendervorgangs wiederum kann zu Mikrorucklern führen. (Das sieht man sehr deutlich an Minecraft, was in Java programmiert ist, wobei das "Mikro" noch sehr schmeichelhaft ist.)
• Java erlaubt kein Überladen von Operatoren. Wenn man viel mit Vektoren, Matrizen usw. arbeitet ist das eine echte Einschränkung. Beispiel:
  Code:
  1. void main(void)
  2. {
  3.   vec2 vTexCoord = inTexCoord;
  4.   vec3 vN = normalize(mat3(u_ModelMatrix) * inNormal);
  5.   vec3 vPos = vec3(u_ModelMatrix * vec4(inPos, 1.0));
  6.   vec4 gl_Position = u_ModelViewProjectionMatrix * vec4(inPos, 1.0);
  7. }
  Sieht nach GLSL aus, oder? Man kann es in C++ haargenau so schreiben, wenn man für die Klassen vec2, vec3, vec4, mat3 usw. entsprechende Konstruktoren definiert und die Operatoren überlädt.

Neben den Features der Sprache sollte man auch andere Aspekte betrachten. Zum Beispiel Portabilität. Portabilität wird immer als großer Pluspunkt von Java angesehen. Meine Meinung ist da eine andere. Weil Java-Programme üblicherweise als Bytecode ausgeliefert werden, müssen sie auf dem Endgerät des Anwenders zu Maschinencode kompiliert werden. Dazu wiederum ist es notwendig, dass der Anwender eine Java Runtime Environment bei sich installiert hat. Auf Android-Smartphones ist das zwar immer der Fall, auf dem Desktop kann man es dagegen nicht voraussetzen.
Programme, die in Maschinencode ausgeliefert werden (Pascal, C, C++), laufen ohne weitere Voraussetzungen. Natürlich muss der Code dann im Gegensatz zu Javacode für jede Betriebssystem-Plattform kompiliert werden. Die Anpassung an die Plattform wird also bei Java vom Entwickler zum Anwender verschoben.

Weitere Aspekte, die bei der Wahl der Sprache interessant sein könnten, sind die Menge und Qualität der verfügbaren Tools, IDEs und Code-Libraries.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Hey,



wie Sascha schon gesagt hat ist das ne Einstellung. Und zwar kompiliert er die Debug infos mit in die Exe rein. Dadurch wird die unnötig groß. Normalerweiße nimmt man die Debug-Infos beim Release raus, dann wird die Exe sogar kleiner als die von Delphi. Da gabs mal iwo n cooles Diagramm dazu, aber frag nich wo^^ In meinem Projekten lager ich die Debuginfos immer in eine seperate Datei aus. Dann muss ich nich nochmal ein extra Release bauen sondern kann gleich die Debug-Exe nehmen, da ja eh keine Debug-Infos mehr drin sin.
Die Einstellungen findest du hier: Projekt -> Projekteinstellungen -> Debuggen -> Externe Datein mit gdb-Debugsymbolen nutzen (-Xg)

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Ich glaube, du meinst etwas anderes als hier steht. Java und C# werden nicht in nativen Code kompiliert, das passiert (optional) Just-In-Time zur Laufzeit. Der Einfachheit und Klarheit halber wäre ich dafür, Just-In-Time-Kompilieren und klassisches vorweg kompilieren klar zu unterscheiden. Ich weiß nämlich ehrlichgesagt nicht, was von beidem D jetzt tut.

Weil du damit sagen kannst: Factory-Pattern am Hintern. Die gesamte Delphi bzw. Lazarus Komponentenbibliothek hat einen constructor Create(AOwner: TComponent); virtual;. Da es in einer ordentlichen™ Sprache Klassen first order sind, kann man beim Initialisieren z.B. eine Klasse als Argument geben (meinetwegen TFoobar, welches von TComponent erbt) und das dann so erzeugen:

Das kann man dann mit einer Klasse und einem Owner als Argument aufrufen. Man bestimmt also von außen, welche Klasse da erzeugt werden soll, und das ist extrem mächtig.

Zugegeben, in C++11 kann man inzwischen etwas ähnliches und in mancher hinsicht mächtigeres machen (std::function anyone?), aber so ganz in der Form, wie Object Pascal das kann, ists leider nicht.

Aber das nur als erläuterung, ich will jetzt keinen Sprachenkrieg vom Zaun brechen (daher war mein erster Kommentar auch sehr kurz).


Recht haben Sascha und Bergmann – man muss halt die ganzen Debugsymbole in Lazarus ausschalten, wenn man sein Programm an den Endanwender ausliefern will. Die Bibliothek, die Lazarus mitbringt, ist groß, daher gibts auch viele Debugsymbole. Hatte dazu mal was geschrieben, vielleicht haben Sascha und oder Bergmann da ja noch was hinzuzufügen.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich habe mich in der Tat verschrieben. Ich meinte: "im Gegensatz zu C# und Java wird direkt in nativen Code kompiliert." Ich bin mal so frei und habe es editiert, bevor es noch jemanden verwirrt.


Ist das die Größe der Anwendungsdatei oder der verbrauchte RAM?
Wenn es der RAM ist, dann kann man wahrscheinlich leider nicht viel ändern. Das ist natürlich nicht so schön, allerdings könnte man bei der heutzutage üblichen verfügbaren Arbeitsspeichermenge darüber auch hinwegsehen.
Wenn die Executable so groß ist, dann solltest du die Compiler oder Linkereinstellungen überprüfen. Möglicherweise wird irgendeine große Bibliothek statisch gelinkt oder/und es sind Debugsymbole drin. Man sollte auch die Optimierungseinstellung nochmal überprüfen. Wenn es wirklich darauf ankommt, gibt es ja auch noch Packer wie UPX. In der Regel, außer es gibt einen speziellen Grund, würde ich aber auf soetwas verzichten.

Die für mich entscheidendste Sache ist eher, dass es keine Value Typen gibt. Wenn man nicht fürchterlich aufpasst handelt man sich leicht Seiteneffekte ein und man muss sehr häufig sinnlos kopieren. Wie man in Java überhaupt effektiv einen VertexBuffer zusammenbauen soll ohne Wertetypen ist mir ein Rätsel. Das fehlen von Wertetypen hat mich beim letzten Kontakt mit der Sprache dazu gebracht, einfach überall X, Y, Z Variablen direkt anzulegen anstatt so eines Referenztyp-Vektors. Ist auch kaum mehr Arbeit als die Scherereien die man sonst hat.


In C++ (und D ) kann man generell sehr viele Dinge erweitern und die Sprache ist auf Mächtigkeit ausgelegt. Das heißt, Dinge die in anderen Sprachen einfach nicht gibt, Ende, kann man in C++ direkt umsetzen. Die Vektoren würde ich allerdings besser als Template definieren. 1. Templateparamter: Dimension 2. Templateparamter: Type
Das erspart einen das "Ich darf die selbe Sache 10 mal schreiben"-Dilemma wenn man in Java oder C# eine Vektorstruktur anlegen will. Einmal für 2 * int, Einmal für * 2 float und für double und uint und für 3 Dimensionen und für 4 und für...
Ein weiterer Vorteil ist: Man kann den Templateisierten Vektor wiederum selber in anderen Templates einsetzen und die Typen festsetzen. Dann braucht es kein "std::conditional" oder andere komplizierte Verbiegungen.


Da sieht es bei C++/C sehr gut aus. Auch bei C# habe ich sehr gute Erfahrungen gemacht. Java prinzipiell auch, aber was Tools zur Grafikprogrammierung angeht sieht es meines Wissens nicht optimal aus. Bei D, das ich erwähnt hatte, sieht es da natürlich am magersten aus.

Und damit man am Ende nicht immer mit spitzen Klammern arbeiten muss, kann man sich die wichtigsten Typen typedef'en:

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Naja dann werden wir mal die Exotenkeule schwingen. Objective-C ist von allen OOP-Sprachen die ich bisher gesehen habe die coolste:
+ Sie ist im Gegensatz zu C++ 100% mit C kompatibel. Sprich es gibt keine Features, wie etwa das Typsystem von C++, die im Widerspruch zu C stehen.
+ Die Sprache und Runtime sind sehr einfach gehalten und die Runtime kann sehr leicht durch neue Features erweitert werden. (beliebt sind z.B. Aspekte)
+ Klassen und Funktionsnamen sind auch Objekte und alle Objekte sind normale C structs.
+ Jedes Objekt besitzt einen String der das Layout beschreibt -> Reflektion und co.

- ein wenig schlechtere Performance, da ein Großteil zur Laufzeit gemacht wird (bei Runtimes von Next, GNU und Gnustep sogar extrem schlechte Performance)
- keine gute IDE außerhalb der Apple-Welt
- keine Tutorials oder Bücher (nur speziell für Next-Runtime)

_________________
Meine Homepage

Dank dieser Einstellung ist die EXE von 15MB auf 1,8MB geschrumpft. Danke.
Somit wird Lazurus für Windows-Programme für mich sehr warscheinlich erste Wahl bleiben.

Somit könnte man getrost Java nehmen. Wie sieht es mit EXE aus, kann man solche auch erzeugen, da man nicht umständlich java HelloWorld eingeben muss ?


Ist sowas unter Delphi auch möglich ? Ich habe unter Lazarus dies probiert.

Schön währe wen sowas gehen würde:

So wie es in den Shadern möglich ist.

Nun zurück zu den Programmiersprachen.
Es wird viel über C++ geschrieben. Währe es eine Empfehlung, Android-Aps mit C++ zu schreiben. In Eclipse finde ich C/C++ nur für Windows-Java. AIDE (IDE für Android), da gibt es C/C++.

_________________
OpenGL

such mal die google i/o videos.

_________________
Meine Homepage