Qt/C++: Objektorientierte DLLs und das plattformübergreifend

[EConvertError]

Hallo!

Habe wieder eine Frage, die sich auf C++ mit Qt bezieht - ich hoffe, ihr könnt mir dennoch helfen.

Ich möchte einige Klassen (von QObject abgeleitet) in externe Bibliotheken auslagern und diese dann in versch. Programmen verwenden. Das Ganze soll noch plattformübergreifend sein (also kein COM, soll auch auf Linux/Mac laufen), da sonst der Vorteil von Qt verloren geht.

Der Grund, weshalb ich das hier in einem Delphi-Forum frage: Sollte es nicht (ohne weiteres) möglich sein, wird das Projekt in Delphi ausgeführt, da ich dann auf die Plattformunabhängigkeit verzichte.

Vielen Dank,
Andreas

[Astat]

Hallo EConvertError, sollte doch mit FPC ohne Probleme möglich sein. :gruebel:

http://wiki.freepascal.org/FPC_and_Qt

lg. Astat

[EConvertError]

Vielen Dank für deine Antwort!

Das steht aus verschieden Gründen nicht zur Diskussion. Das Projekt wird entweder in C#/Oxygene (Chrome)/WPF realisiert, oder in C++.

Daher ist für mich entscheidend, wie ich gemeinsame Klassen in C++/Qt für mehrere Programme anbieten kann. Das ist selbstverständlich nicht der einzige Aspekt bei der Entscheidung...

lg,
Andreas

[Assertor]

Hi EConvertError,

wenn Du den Projektmanager überzeugen kannst: Geduld haben, vielleicht kann man statt C++/QT irgenwann Delphi für Cross-Compilation nutzen...

Laut Allen Bauer ist da ja seit Mitte 2009 was in der Pipeline:
http://blogs.embarcadero.com/abauer/2009/05/20/38885

Natürlich kann man noch nicht sagen, ob und wann da was nutzbares bei rauskommt - aber klingt imo doch interessant...

Gruß,
Assertor

Edits: Typos und Gestammel korrigiert ;)

[mkinzler]

Konnte man doch schon einmal (clx)

[Assertor]

Hi,

Zitat:

Zitat von mkinzler

Konnte man doch schon einmal (clx)

Richtig, aber wer würde clx heute auskramen für ein neues Projekt? Und das dann sogar produktiv einsetzen...

Gruß,
Assertor

[Astat]

Zitat:

Zitat von EConvertError

Vielen Dank für deine Antwort!
Das steht aus verschieden Gründen nicht zur Diskussion. Das Projekt wird entweder in C#/Oxygene (Chrome)/WPF realisiert, oder in C++.

Hallo EConvertError, mit C#/Oxygene (Chrome)/WPF oder C++, hast du die gleichen Probleme.
Als einzige Möglichkeit sehe ich ANSI C, sonst gibts irgendwo und irgendwann sowieso Probleme.

lg. Astat

[EConvertError]

Hallo!

Cross-Compilation und Delphi für Win32 kommt auf keinen Fall in Frage. Wenn man sich ansieht, wie lange schon ein 64-bit-Compiler versprochen wird, weiß man warum.

Das Programm soll auf einer soliden und zukunftsträchtigen Architektur aufbauen und daher stehen C++/Qt oder Oxygene/C#/WPF zur Diskussion. Wir fragen uns allerdings, ob man mit C++/Qt wirklich so einfach plattformunabhängigen Code schreiben kann. Wichtig unter anderem ist die Frage, ob man objektorientierte DLLs/shared libraries verwenden kann... Gerade wenn man dazu COM oder sowas verwenden müsste, hätten wir keine Plattformunabhängigkeit mehr.

Es wird im übrigen ein wissenschaftliches Projekt, wichtig ist "Scientific Computing", Graphikprogrammierung (vorerst 2D, später auch 3D).

Daher würde mich eine genauere Erläuterung deiner Antwort interessieren, Astat. Qt wird doch als plattformunabh. Lösung angepriesen, warum also werde ich da auf die gleichen Probleme stoßen?

Danke,
Andreas

[Astat]

Zitat:

Zitat von EConvertError

.. ob man mit C++/Qt wirklich so einfach plattformunabhängigen Code schreiben kann. Wichtig .. ist .. ob man objektorientierte DLLs/shared libraries verwenden kann... Gerade wenn man dazu COM oder sowas verwenden müsste, hätten wir keine Plattformunabhängigkeit mehr.

..Qt wird doch als plattformunabh. Lösung angepriesen, warum also werde ich da auf die gleichen Probleme stoßen?

Hallo EConvertError, nicht bei Qt, sondern bei C++, C# entstehen Probleme bei der Plattform unabhängigkeit.
C++ Objekte können nicht ohne weiteres in anderen Sprachen verwendet werden.
Auch gibt es unterschiedliche C++ Dialekte. Desshalb meinte ich, dass alle öffentlichen Schnittstellen ANSI-C sein sollten.

Selbst Qt-Programmierung hat eigentlich nichts mehr mit C++ zu tun, da die gesammte Implementation auf C-Makros
aufgebaut ist. Da entstehen zwangsläufig Problemem im Namespaces, auch sind diese nicht typsicher.
Also wenn es um Platform unabhängigkeit geht, dann "Innen" Qt aussen "ANSI-C"

In welcher Sprache dann die Qt- Container sind, ist dann Nebensache.

lg. Astat

[EConvertError]

Ich möchte anmerken, dass die Anforderung an öffentliche Schnittstellen nicht ist, dass JEDER in JEDER Sprache darauf zugreifen kann. Ich würde ohnehin nur Qt mit C++ verwenden.

Aber ich verstehe das Problem und danke für die Hilfe!

lg,
Andreas