machen wir es für C++ Builder kurz:
+ das einzige was dafür spricht ist die Tatsache, das man damit per FMX(wenn Enducation RSpro) automatisch auch OSX, und Mobile(Android&IOS) als
RAD Lösung für GUIs dabei hat und Delphi zum debuggen der ganzen
PAS Teile
RTL,FMX,...
- dagegen spricht das der C++ Builder intern kein echtes C++ System ist, sondern auf Delphi(Pascal) aufsetzt und somit die
RTL,
VCL/FMX und
GUI bezüglich der C++ Konstrukte absolut inkomatibel zum Rest der Welt sind und daher eigentlich niemand den C++ Builder zu mehr nimmt als mal ein paar non
GUI C++ Sachen 1:1 schnell ohne umschreiben direkt in ein Delphiprojekt zu bekommen
Eine Masterarbeit ist ja quasi auch der Einstieg ins Berufsleben...
Erfahrung mit C++ Builder ist da ohne Bedeutung. Erfahrung mit VisualStudio und/oder VC++ gehört aber zur Standard MustHave Liste wenn es um "C" Jobs geht. Auch unter anderen Studenten ist die Chance jemanden mit VS / VC Kenntnissen fragen zu können viel größer.
=> VisualStudio mit VC++ nehmen und wenn Zeit&Lust weil C++ ja ohne
GUI "portabel" ist(sein soll/kann
) dann noch per kostenlosem AppMethod C++ per FMX auf Android als MobilGUI zum Nachweis der sauberen & portablen Trennung von Funktion(Standard C++Klassen) und Design(C++Builder
GUI-Klassen) realisieren
Das enttäuscht mich jetzt aber kolossal, bin eigentlich wegen eines anderen Problems hier und sehe gerade den Strang.
Ich hatte gehofft, daß auch in der
GUI die Komponenten wenigstens binärkompatibel zum Rest der Welt sind.
Warum einigt man sich da nicht auf einen Standard?
AUßerdem gibt es die Interfaces, die
Com-Objekte und anderes um das Zeug portabel zu machen. Warum funktioniert das dann im konkreten Fall nicht?
Wenn der C++ Builder Delphi Komponenten verwenden kann, heißt das ja schon mal, daß die Komponenten aus den gleichen Haus binärkompatibel seine mussen.
Wie steht es denn da diesbezüglich bei den GNU Tools?
Könnte ich dort mit GCC Lazauskomponenten verwenden, um damit unter Benutzung von GCC oder der
IDE wxDevc++ eine
GUI Anwendung zu bauen?