C++ Builder oder Visual C++

[MrSpock]

Hallo,

meine Tochter fängt demnächst Ihre Master Arbeit an. Dazu soll Sie eine Anwendung in C++ schreiben. Ich als Delphi Fan würde ihr dazu den C++ Builder empfehlen (kostet als Student ca. 130€ für das RAD Studio Professional). Obwohl in Microsoft nicht mag, muss ich zur Kenntnis nehmen, dass es eine Alternative zum C++ Builder, nämlich Visual C++ gibt. In der community edition für Studenten kostenlos.

Was spricht für bzw. gegen die beiden Systeme und was würdet ihr aus Erfahrung heraus empfehlen?

[jfheins]

Ich konnte bisher nur mit der C# Seite von Visual Studio Erfahrungen sammeln (6 Monate), würde die IDE aber als sehr gut bewerten.
Fehlerhaftes Error-Insight hatte ich quasi nicht, die IDE "fluppt" auf einem aktuellen PC gut, das springen zu Definitionen funktioniert sehr gut und es gibt git-Integration

Ich persönlich würde das auf jeden Fall mal ausprobieren, bevor ich das Geld investiere.
Ich sollte vll. noch dazu sagen, meine letzte Delphi-Version war 2006.

[Zacherl]

Vom Komfort her ist Visual Studio meilenweit vorraus. Setzt man dann noch Plugins wie Resharper (https://www.jetbrains.com/resharper-cpp/) ein, welche es als Student übrigens gratis gibt, programmiert sich die Anwendung praktisch schon von alleine

Auch wegen der Kompatibilität zu anderen OpenSource Projekten und Libs her, würde ich definitiv auf Visual Studio statt C++ Builder setzen. Letzterer konnte sich nie wirklich durchsetzen und ist in den meisten Kreisen eher "verpöhnt".

Die nicht-community-Edition von Visual Studio gibt es an den meisten Unis übrigens auch gratis über das MSDNAA.

[mensch72]

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

[Der schöne Günther]

Hatte einen Teil meiner Abschlussarbeit auch in C++ im Visual Studio geschrieben und kann mich den anderen nur anschließen: Nehmt das. Der IDE-Komfort allein ist es schon wert.

[TiGü]

Die letzte C++ Builder Version, die ich in der Hand hatte, war XE3.
Hier ist die Code-Vervollständigung der Wahnsinn, d. h. so gut wie nicht existent.
Kleinste Fehler während des Schreibens des Quelltextes sorgen dafür, dass du keine Möglichkeit hast - und du brauchst das unbedingt als Einsteiger - die Codevervollständigung aufzurufen.

Dagegen ist Visual Studio mit der IntelliSense Lichtjahre voraus.
Zusammen mit so Add-Ons wie Visual Assist (http://www.wholetomato.com/) eindeutig die bessere Wahl.

Die IntelliSense basiert auf einer Datenbank, die im Hintergrund pro Projekt aufgebaut wird, während die Codevervollständigung der C++ Builder IDE im Hintergrund versucht zu kompilieren. Ein , statt . und schon ist das aus dem Tritt.

[Bernhard Geyer]

C++ - Mein Beileid.

Ist das die einzige Vorgabe? Oder gibts noch was wie "Lauffähigkeit unter Linux" oder ähliches?

[DualCoreCpu]

Zitat von mensch72:

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?

[uligerhardt]

Zitat von DualCoreCpu:

Warum einigt man sich da nicht auf einen Standard?

https://xkcd.com/927/

Vermutlich, weil keiner Interesse daran hat - Vendor-Lock-In aufgeben etc. Oder viel banaler, weil's ein Riesenhaufen Arbeit wäre und den Kunden die Rückwärtskompatibilität ihrer Projekte wegnehmen würde.

[MrSpock]

Rückmeldung des Betreuers:

Alle Systeme dort sind Linux basiert und nutzen OpenVC und Python. Er hat aber noch einmal bestätigt, sie kann jedes Environment unter Linux oder Windows benutzen. Er hatte in der vorherigen Besprechung zusätzlich noch gesagt C++ sei die Empfehlung, und sie solle nicht Java oder C# benutzen.