Moin moin!

Ich möchte in der nächsten zeit ein Projekt realisieren das möglichst Crossplattform fähig ist, dazu sind mir folgende Möglichkeiten eingefallen:
-Delphi/Kylix
-C++ und QT/GTK
-Java
-Python
-.NET
Mein Problem ist die Entscheidung zu treffen welche ich benutzen soll, habt ihr da Links parat wo man sich informieren kann?

Mit dem Projekt würden folgende Unterstützungen gebraucht:
-XML(große Datenmengen)
-TCP/IP
-Schnittstellenzugang
-2D (Beschleunigung)(GDI++?)
-3D Beschleunigung(OpenGL)
-Schnelligkeit
-ASM Einbindung
-Plugin Fähigkeit
-Sound,Drucken

Alle Sprachen haben Vor und Nachteile:
Delphi:
-kenn ich mich einigermaßen aus (aber nicht mit Kylix)
-nur WIN/Linux

C++:
-nur rundimentäre Erfahrung
-Anpassung an jede Plattform

Java:
-nur rundimentäre Erfahrung
-nicht sonderlich performant(naja ohne das nötige KnowHow:()

Python:
-keine Erfahrung mit

.Net:
-keine Erfahrung mit
-Kompatibilitätsprobleme .NET FW 1.x, 2.x, Mono

Vielleicht hat einer von euch ja schon Erfahrung mit solch schwerwiegenden Entscheidungen, soll nämlcih was größeres werden und OpenSource :/

digi_c hat folgendes geschrieben:

Java: -nicht sonderlich performant(naja ohne das nötige KnowHow:()

Vor allem ohne 3D-Beschleunigung soweit ich weiß.
Die Schnelligkeit für normale Anwendungen, besonders was die Startzeit anbelangt, kann man mit dem JBuilder sehr gering halten.

digi_c hat folgendes geschrieben:

.Net: -keine Erfahrung mit -Kompatibilitätsprobleme .NET FW 1.x, 2.x, Mono

Das gibts ja noch nicht ernsthaft für andere Plattformen! Mono läuft noch nicht mit allen Programmen und stürzt bei mir zu oft ab.

Grundsätzlich würde ich C++ für die beste Sprache halten, da du allerdings kaum Erfahrung damit hast, dürfte das schwierig werden. Denn C++ ist doch ziemlich kompliziert, was ich aus eigener Erfahrung weiß...

Was Delphi anbelangt: Das dürfte kaum für 3D-Anwendungen geeignet sein, wenn die nach Linux portiert werden sollen. Da gibts zwar inzwischen Open-Source, mit der das möglich sein soll, aber was wirklich gutes hab ich da noch nicht gesehen, was sowohl mit Delphi als auch mit Kylix wirklich gut läuft.
Dennoch: Wenn du mit Delphi klarkommst, ist das ganz gut geeignet, denn bis auf 3D sollte alles andere relativ einfach portabel für Windows UND Linux gemacht werden können.

Das beste ist wohl: Versuch mit C++ Programme zu schreiben, und wenn du das hinbekommst, d.h. mit C++ arbeiten kannst, dann nimm das.
Und wenn du nicht erst C++ lernen willst und sofort anfangen willst, dann nimm Delphi, auch wenn das dann nicht für so viele Plattformen taugt.

Wobei ich an dieser Stelle auch noch auf FreePascal und ähnliche Projekte hinweisen möchte, die auch unter anderen Systemen Portabilität herstellen. Nachteil: Die Kompatibiblität mit Delphi ist nicht so toll.

Es gibt noch eine weitere Alternative: Lazarus. Ist ein freier Delphi Klon auf FreePascal Basis. Du kannst damit Cross Platform auf folgenden Grafikbibliotheken programmieren: GTK bzw. GTK2, Gnome, Qt, Carbon (Mac OS X) und WinAPI (Win32 Forms). Ist noch nicht komplett ausgereift, aber bietet sich für jemanden mit umfangreichen Delphi Kenntnissen an.

die frage is ja: willste ein prog haben was auf allen plattformen oder zumindest auf mehreren läuft oder willste ne ide womit du für mehrere palttformen proggen kannst aber das prog läuft dann eben nur auf dieser plattform.
fürs erste fällt mir nur java ein weil das mit der virtualmaschine(oder wie schreibt man das?) läuft.
fürs zweite gehn sicher delphi, c++, etc. brauch man glaub ich nur für jede plattform nen anderen compiler und die systembefehle sind anders...
korrigiert mich wenns falsch is

Hallo,

digi_c hat folgendes geschrieben:

-ASM Einbindung

das wirft die Frage auf, was du unter "Plattformunabhängig" verstehst? Nur Windos + Linux oder darf es auch mal auf den Mac oder einen Pocket PC gehen? Dann kannst du den Punkt (zumindest Platformübergreifend) nämlich schon vergessen.

Gruß
Klabautermann

jaenicke hat folgendes geschrieben:

Vor allem ohne 3D-Beschleunigung soweit ich weiß.

Klar gibt es 3D für Java...

Zitat:

Die Schnelligkeit für normale Anwendungen, besonders was die Startzeit anbelangt, kann man mit dem JBuilder sehr gering halten.

Hmpf?
Was soll JBuilder da anders machen? Vor allem, da er den gleichen Compiler nimmt, wie alle anderen.
Die lahmarschige Swing-darszellung lässt sich IMHO nur mit SWT kurieren, wobei wieder ein Teil XPlattform wegfällt.

Zitat:

Das gibts ja noch nicht ernsthaft für andere Plattformen! Mono läuft noch nicht mit allen Programmen und stürzt bei mir zu oft ab.

Wie kann mono abstürzen? Hat das hier noch jemand erlebt?
Möglich ist, dass deine Apps eine type load/NotImplemented Exception werfen und sich in Wohlgefallen auflösen.

Erteres lässt sich ziemlich easy lösen wenn man seine C# Sources gegen den C# compiler von Mono kompiliert.
Als Chrome-Entwickler hat man es da einfacher, da kann man direkt im VisualStudio gegen Mono/pNet kompilieren[meta]der compiler selbst läuft übrigens auch auf den Plattformen[/meta].

Wenn man es geschickt anstellt, kann man so ganz easy testen, ob die App auf Mono läuft. Du kannst dir sogar mono debug Symbole erzeugen lassen. (.mdb)

Es gibt aber noch Probleme bei .Net2.0<->Mono:

• 2.0 hat ein anderes Resource Format, mono verwendet das alte von 1.1
  
• mono hat eine gute Umdeckung von COntrols us SWF1.1, aber keine von SWF2.0[meta]Zum Bleistift die coole DataGridView oder BindingSource[/meta]

portable .Net aka dotGNU würde ich komplett links liegen lassen.
Die Jungs sind so damit beschäftigt MS schlecht zu machen, dass sie immer noch nicht gerallt haben, dass ihr IL Interpreter[meta]Das ist wie Java vor 10 Jahren[/meta] einfach erbärmlich ist.

Die Wahl liegt also eigentlich bei .Net 1.1 <-> mono, Java oder gar nicht.
Diese ganzen Friemleleien mit GTK, QT, whatsoever mit irgendeinem gcc, laufen doch nur darauf hinaus, dass man keine moderne IDE wie VisualStudio benutzen kann. Wenn du masochistisch veranlagt bist, kannst du es ja gerne so machen...

Wobei es GTK auch als managed Version gibt. Nur GTK ist hässlich! (Es gibt zwar auch weniger hässliche Themes, aber alle ignorieren, die Styles in XP, oder andere User Einstellungen)
Zu dem Punkt kann tommie vllt noch tröstende Worte finden.

Zitat:

Was Delphi anbelangt: Das dürfte kaum für 3D-Anwendungen geeignet sein, wenn die nach Linux portiert werden sollen. Da gibts zwar inzwischen Open-Source, mit der das möglich sein soll

Hää?

Zitat:

Wobei ich an dieser Stelle auch noch auf FreePascal und ähnliche Projekte hinweisen möchte, die auch unter anderen Systemen Portabilität herstellen. Nachteil: Die Kompatibiblität mit Delphi ist nicht so toll.

Das war/ist IMHO auch die größte Dummheit, die die FPC'ler machen konnten:
Eine Kopie einer Sprache, die in fast allen Bereichen hinterherhinkt. Die haben ja sogar einen mittellterlichen single pass Compiler gebaut, nur um "kompatibel" zu sein.
Sorry FPC halte ich für witzlos...

1. Es hat nichtmal Packages
   
2. optimiert es noch nicht richtig
   
3. gibt es keine IDE mit einem brauchbaren Code Editor
   
4. die erzeugten binaries ind unglaublich groß.

*an Kopf greif*

Wieder mal solche Fragen ...

Zu allererst einmal bzgl. ASM: ASM ist ein nettes Gimmick, hat aber in einer Cross-Platform-Anwendung nichts für den Allgemein-Part zu suchen. D.h. jedes ASM-Snippet, was Du per ASM ansprichst, MUSS auch als High-Language-Source verfügbar sein. Ich kanns nur immer wieder sagen; hab selbst damit etwas zu kämpfen, wenn ich eins meiner jetzigen Projekte auf FPC erweitern will.

Von daher: Finger weg von ASM, wenn's nicht unbedingt notwendig ist!

Ansonstn zu Delphi und 3D: Bitte einmal in den DelphiGL-Header für OpenGL reingucken ...
Der läuft mit nahezu jedem Pascal-Compiler (u.a. auch Delphi, Kylix, FPC, TMT-Pascal, IIRC sogar BCB). Von daher bitte Vorsicht mit Äußerungen wie "3D läuft nicht mit Delphi - es läuft sogar stellenweise genausogut wie unter C++.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Robert_G hat folgendes geschrieben:

Sorry FPC halte ich für witzlos... Es hat nichtmal Packages optimiert es noch nicht richtig gibt es keine IDE mit einem brauchbaren Code Editor die erzeugten binaries ind unglaublich groß.

zu
a) wenn du damit VCL kompos meinst, klar. units sind jedenfalls dabei
b) hast du dafür irgendwelche anhaltspunkte
c) badhim.h11.ru/
d) verwechsle nicht FPC mit lazarus. FPC-binaries sind nur ca 25 % grösser als ihre delphi pendants.

Eine nette IDE für FreePascal ist auch Dev-Pascal.

Muffin hat folgendes geschrieben:

Eine nette IDE für FreePascal ist auch Dev-Pascal.

aber extrem hässlich, man fühlt sich in win3.11 zeiten zurückversetzt.
ausserdem ist die verwaltung von resourcen (formulare etc.) äusserst umständlich.

retnyg hat folgendes geschrieben:

a) wenn du damit VCL kompos meinst, klar. units sind jedenfalls dabei b) hast du dafür irgendwelche anhaltspunkte c) badhim.h11.ru/ d) verwechsle nicht FPC mit lazarus. FPC-binaries sind nur ca 25 % grösser als ihre delphi pendants.

1. Packages == spezielle DLLs, die ohne Krämpfe als class libraries benutzt werden können.
   Der Mangel zeigt sich an Lazarus, das wegen jeder neuen Komponente mal eben neu kompiliert werden muss.
   Prost Mahlzeit!
   
2. ewig nicht angeschaut, beim letzten Mal war das Delphi-Kompilat signifikant schneller
   
3. Das Ding war jetzt hoffentlich ein Witz, oder?
   
4. Lazarus ist doch eine IDE für den FPC, warum sollte ein Unterschied zwischen Kompilierung innerhalb Lazarus und außerhalb bestehen?

Aber lass mal... viel zuviel über FPC geschrieben. Der Krempel interessiert mich eigentlich nicht wirklich.
Mein Punkt war eigentlich, dass es zu friemelig und eingeschränlt ist um als Plattform für ernsthafte Entwicklung zu dienen.
Da würde ich sogar das Gefriemel mit Mono vorziehen...

Robert_G hat folgendes geschrieben:

retnyg hat folgendes geschrieben: a) wenn du damit VCL kompos meinst, klar. units sind jedenfalls dabei b) hast du dafür irgendwelche anhaltspunkte c) badhim.h11.ru/ d) verwechsle nicht FPC mit lazarus. FPC-binaries sind nur ca 25 % grösser als ihre delphi pendants. Packages == spezielle DLLs, die ohne Krämpfe als class libraries benutzt werden können. Der Mangel zeigt sich an Lazarus, das wegen jeder neuen Komponente mal eben neu kompiliert werden muss. Prost Mahlzeit!

Seh ich anders. Rede bitte nicht von Dingen, von denen Du nichts verstehst. FPC kann sehr wohl Packages und unter Lazarus wird das auch genutzt. Dass der Support für diese unter FPC zu wünschen übrig lässt, ist eine andere Geschichte. Da muss ich aber zustimmen: Da besteht echter Verbesserungsbedarf. Übrigens: Delphi ist in der Hinsicht auch nicht besser ... Auch wenn Borland Packages eingeführt hat, können die nichtmal die Hälfte von dem, was machbar ist. Man denke nur an Exportierte Variablen (z.B. in C++ möglich).

Robert_G hat folgendes geschrieben:

ewig nicht angeschaut, beim letzten Mal war das Delphi-Kompilat signifikant schneller

Na und? Wichtig ist nicht, wie schnell der Kompiler ist, sondern sein Kompilat. Und da liegt ATM der FPC um Weiten vorn, wenn man die richtigen Einstellungen nutzt. FPC ist in Sachen Optimierung und Feature-Set-Support der CPUs wesentlich besser, als der Delphi-Compiler, der selbst in der 7er Version nur i386-kompatible Binaries ausgibt und MMX, SSE und 3DNow nur als Gimmick bei ASM-Programmierung unterstützt.

Robert_G hat folgendes geschrieben:

Das Ding war jetzt hoffentlich ein Witz, oder?

Dazu enthalte ich mich mal. Hab bisher noch keinen Blick drauf werfen können.

Robert_G hat folgendes geschrieben:

Lazarus ist doch eine IDE für den FPC, warum sollte ein Unterschied zwischen Kompilierung innerhalb Lazarus und außerhalb bestehen?

Schonmal deinen Programmier-Stil MIT und OHNE Delphi-IDE verglichen? Deiner Antwort nach nicht. Gut, also will ich es Dir mal so erklären:

Wenn man mit einer IDE arbeitet, die die meisten Dinge schon von Haus aus macht, kommt man leicht in Versuchung Platz und Ressourcen zu verschwenden.
Wenn man dagegen ohne IDE programmiert, würde keiner auf die Idee kommen, DFM-Dateien für Formulare zu nutzen, sondern jegliche Komponenten-Platzierungen per Source vorzunehmen, bzw. ganz\teilweise auf die VCL verzichten, wodurch einiges an Größenunterschied der resultierenden Binaries erzeugt (nominal 300 KB leeres VCL TForm, 16 KB leeres Fenster mit reiner WinAPI). Es existieren noch einige andere Unterschiede, aber das ist einer der wichtigsten: IDEs verleiten zum Ressourcen-Verschwenden!

Robert_G hat folgendes geschrieben:

Aber lass mal... viel zuviel über FPC geschrieben. Der Krempel interessiert mich eigentlich nicht wirklich. Mein Punkt war eigentlich, dass es zu friemelig und eingeschränlt ist um als Plattform für ernsthafte Entwicklung zu dienen. Da würde ich sogar das Gefriemel mit Mono vorziehen...

Guten Tag Metzger, ich bin Vegetarier. Was haben Sie im Angebot?

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Danke erstmal für die vielen (wenn auch wiedersprüchlichen ) KOmmentare, also meine Überlegungen sind folgende:
1.Mach ich es erstmal für eine Plattform und überlasse anderen die Anpassung an andere OS? oder Lieber gleich in einer unabhängigen Version(die müsste dann aber den Konfort einer IDE und eines Sources haben also ohne MAKE und ohne Compilerschalter und hinundher geswitchte Funktionen à la C/C++)
2.ASM spielt ein wenig auf Optimierung durch Plugins an, kann also auch durch DLLs,... eingebunden werden also kein Inline
3.Die Oberfläche sollte sich zu 100% in WIN anpassen, das ist ein wesentlicher Grund wieso ich das Projekt machen will.
4.3D+OpenGL sind IMHO auf fast jeder Sprache verfügbar
5.Es sollte natürlich möglichst weit verbreitet sein, PDA Unterstützung denkbar aber sehr abgespeckt.

Tja aber so richtig bin ich noch nicht entschlossen was nun nehmen, FreePascal/Lazarus wäre ja für ein OS Projekt interessant. Java aber auch relativ verbreitet:|

Och mönsch, kann es sein, dass du Dinge in den Text hineinliest, die du lesen _wolltest_?

Zitat:

Seh ich anders. Rede bitte nicht von Dingen, von denen Du nichts verstehst. FPC kann sehr wohl Packages und unter Lazarus wird das auch genutzt. Dass der Support für diese unter FPC zu wünschen übrig lässt, ist eine andere Geschichte. Da muss ich aber zustimmen: Da besteht echter Verbesserungsbedarf. Übrigens: Delphi ist in der Hinsicht auch nicht besser ... Auch wenn Borland Packages eingeführt hat, können die nichtmal die Hälfte von dem, was machbar ist. Man denke nur an Exportierte Variablen (z.B. in C++ möglich).

Das letzte Mal, als ich Lazarus benutzt habe, musste es für jede Kompnente neu kompiliert werden. Warum sollte man solchen Blödsinn machen, wenn es Packages gäbe?

Zitat:

Na und? Wichtig ist nicht, wie schnell der Kompiler ist, sondern sein Kompilat.

Autsch! Ich bin doch keiner von diesen *piep*, die eine Sprache nach der Geschwindigkeit des Compilers bestimmen. Ich schrieb nicht umsonst Kompilat.

Zitat:

Und da liegt ATM der FPC um Weiten vorn, wenn man die richtigen Einstellungen nutzt. FPC ist in Sachen Optimierung und Feature-Set-Support der CPUs wesentlich besser, als der Delphi-Compiler, der selbst in der 7er Version nur i386-kompatible Binaries ausgibt und MMX, SSE und 3DNow nur als Gimmick bei ASM-Programmierung unterstützt.

Genau deshalb hatte es mich da auch etwas enttäuscht...

Zitat:

Schonmal deinen Programmier-Stil MIT und OHNE Delphi-IDE verglichen? Deiner Antwort nach nicht.

Ich wüsste nicht, warum ich in NotePad anders programmieren würde, als in einer IDE. Ehrlich gesagt wüsste ich nichtmal warum man sich das antun sollte.
Deine "Erklärung" impliziert[meta]wie jeder zweite Satz in deinem Post[/meta], dass du mich für einen dieser unfähigen "Komponente auf's Form ziehen"-Pseudoentwickler hälst.
Ich schreibe keine GUIs sondern APIs, die von den GUI-Bastlern[meta]welche ebenfalls nicht zu obengenannter Gruppe gehören[/meta] verwendet werden. Genau deshalb kam mir dieser Unterschied Lazarus/nicht Lazarus spanisch vor[meta]Der Impact von GUI Frameworks war weder in meinem noch in retnygs Beitrag zu lesen[/meta].

Zitat:

Guten Tag Metzger, ich bin Vegetarier. Was haben Sie im Angebot?

Anscheinend nix, und anscheinend ist das auch besser für uns beide. So ich bin dann erstmal raus hier. Jetzt weiß ich auch, warum diese Sparte zu OffTopic zählt...

Robert_G hat folgendes geschrieben:

Der Mangel zeigt sich an Lazarus, das wegen jeder neuen Komponente mal eben neu kompiliert werden muss.

fpc <> lazarus

Robert_G hat folgendes geschrieben:

[*]Das Ding war jetzt hoffentlich ein Witz, oder?

nein, wieso ?

Robert_G hat folgendes geschrieben:

[*]Lazarus ist doch eine IDE für den FPC, warum sollte ein Unterschied zwischen Kompilierung innerhalb Lazarus und außerhalb bestehen?

lazarus linkt atm. die komplette FCL ins binary, wodurch selbst winzige programme mb's belegen.
das siehst du am besten wenn du eine hello world konsolen-app machst. mit lazarus über 1mb, mit reinem FPC 40kb, mit delphi standard ca 25 kb.

digi_c hat folgendes geschrieben:

2.ASM spielt ein wenig auf Optimierung durch Plugins an, kann also auch durch DLLs,... eingebunden werden also kein Inline

DLL's gibts nur unter windows...

digi_c hat folgendes geschrieben:

3.Die Oberfläche sollte sich zu 100% in WIN anpassen, das ist ein wesentlicher Grund wieso ich das Projekt machen will.

langer rede kurzer sinn: willst du für die versch. plattformen entwickeln, nimm C/C++.
aus dem einfachen grund dass dafür die benötigten libraries schon auf jeder plattform existieren, und lösungen wie Lazarus noch im Betastadium stecken.

Dann hab ich doch aber immernoch das hin und her geswitche und manuelle Makesoße, von mangelnder RAD ganz zu schweigen

digi_c hat folgendes geschrieben:

Dann hab ich doch aber immernoch das hin und her geswitche und manuelle Makesoße, von mangelnder RAD ganz zu schweigen

RAD ? du willst rapide entwickeln, und das kompilat soll auf jeder plattform laufen
dann nimm lazarus und mach ein 1mbyte grosses "hallo welt".
ne aber jetzt mal im ernst: rapide geht sowas nicht. immerhin musst du dich mit jeder plattform so gut auskennen, dass du features wie openGL implementieren kannst.
mach dich schon mal auf ein langes projekt gefasst.
wenn es nur auf windows/linux laufen soll ist mingw32 vielleicht für dich interessant.

Wollt ja nur ein wenig Konfort und nicht für jeden Button ne essageQueque schreiben

Na mal schaun werd mich wohl noch ein paar Wochen Zeit nehmen müssen für die Entscheidung :/

Darf ich njochmal fragen, ob jemand Foren/Seiten kennt in den man sich zu den verschiedenen Möglichkeiten der Corssplattformentwicklung informieren kann?

Foren kenn ich leider keine und ich hab hier auch nicht alles gelesen.

Aber eines vorab:
Denk an die unterschiedlichen Typen!
Unterschiedliche Architekturen heißt auch andere Größen.
z.B.: ein Integer (4 Byte) x86 ist IMHO bei einer Alpha, Sparc etc. doppelt so groß. (8 Byte)
Deshalb lohnen sich solche Dinge wie z.B.: malloc(sizeof(int)); mehr als malloc(4);
Letzteres geht nach hinten los.

Für die Entwicklung ist die Sprach relativ egal, der Compiler muß Crossplatform kompilieren können.
Inline Assembler würde ich in diesem Fall nicht empfehlen.

Schau dich mal in der Linux-Szene um für mehr Infos.

Edit:// Es gibt ein Projekt, dass sich WxWigdet nennt. (C++)
Das dürfte für dich recht interessant sein, da diese Windowcontrols platformunabhängig konzipiert wurden.