C++ Builder oder Visual C++

[cookie22]

Man kann unter VC++ mit Winforms genauso schnell Oberflächen erstellen, wie unter Delphi.

Mit C++ ist es mittlerweile etwas aufwendiger, weil wohl jeder der VS benutzt, C# für Rad-Development nutzen wird.

https://www.youtube.com/watch?v=AP8Tz9RfbxE

In älteren versionen kann man direkt Winforms-Projkte auch in C++ erstellen.

[MrSpock]

Aber WinForms nutzt doch das .NET framework, oder?

Wie gesagt, habe es mir heute Mittag mal angeschaut und kann im Moment nicht nachvollziehen, warum hier Visual C++ emphohlen wird, wenn nur die .NET framework Version wirklich intuitiv benutzt werden kann und ich sinnvollerweise QT oder so installieren muss, um es halb so intuitiv benutzen zu können wie C++ Builder. Was spricht denn wirklich gegen den C++ Builder? Die VCL sehe ich nicht als Nachteil, sonder als Punkt auf der Positivseite. Ist die Stabilität denn so schlecht? Die letzte Version, mit der wir damals ein paar kleinere Anwendungen geschrieben haben war mit dem C++ Builder 2010.

Wenn Sie Bilbliotheken benutzt, die von der Uni beigestelltr werden, kann sie diese doch im C++ Builder genauso benutzen wie bei Visual C++.Und ob Sie die MFC unbedingt noch "lernen" muss, wenn MS hier immer wieder neue Frameworks einführt, weiß ich auch nicht.

Deshalb noch einmal meine Frage. Habt ihr noch andere Vor- oder Nachteile der beiden Systeme?

[Zacherl]

Zitat:

Zitat von uligerhardt (Beitrag 1320529)

Zitat:

Zitat von Zacherl (Beitrag 1320519)

Einzig und allein das RAII basierte Exception Handling geht mir vom Konzept her ziemlich gegen den Strich.

Komisch - RAII ist das, was ich in Delphi so ziemlich am meisten vermisse.

RAII ansich ist schon recht cool. Nur finde ich das Exception Handling recht umständlich. Mir fehlt sowas wie das gute alte

Delphi-Quellcode:

try

. ScopeGuards finde ich unintuitiv, da hier der

Delphi-Quellcode:

finally

Block praktisch vor dem

Delphi-Quellcode:

try

Block steht und sämtliche Resourcen in extra Klassen zu kapseln (z.b. alle möglichen Arten von Handles bei Verwendung der WinAPI) ist aufwändig und unübersichtlich.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Copy/Move-Semantics-Verstehe ich nicht?

Zu komplex, um das jetzt mit eigenen Worten zu erklären, aber C++ allocated Objekte auf dem Stack und nicht (wie z.b. Delphi) auf dem Heap. Hier hast du jetzt die Möglichkeit Objekte zu "moven" statt zu kopieren. Das hat unter anderem Performance-Vorzüge und ist auch oft semantisch sinnvoll (unique_ptr, etc).
Wenn es dich sehr stark interessiert, dann findest du hier eine ausführliche Erklärung im Rahmen des Copy-Swap-Idioms:
http://stackoverflow.com/a/3279550

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Templates - Für was was man mit anderen Sprachfeatures nicht genauso gut lösen kann.

Das Template System ist eine komplette funktionale Programmiersprache, die in C++ eingebettet ist. Normale Generics können hier einpacken und die Delphi Generics erst recht :-D
Sehr mächtig sind auch Template-Spezialisierungen. Grob gesagt hat man ein Grund-Template mit einer bestimmten Signatur und darüber definiert man beliebig viele spezialisierte Templates, die z.b. eine bestimmte Klasse / einen bestimmten Datentyp matchen. Die STL hat beispielsweise eine Art Array Implementation namens std::vector, die man über

Code:

std::vector<int>

deklarieren kann. Wie ein normales Array in Delphi reserviert die Klasse intern dann für jedes Element sizeof(int) an Speicher. Verwendet man aber einen

Code:

std::vector<bool>

nimmt der Compiler das für bool spezialisierte Template und arbeitet intern mit Bitfields, weshalb 8 Werte nicht mehr 8, sondern nur noch 1 Byte belegen.

Zitat:

Zitat von MrSpock (Beitrag 1320578)

Was spricht denn wirklich gegen den C++ Builder?

1. Kostet Geld.
2. Steinzeitliche IDE (schlechte Code-Completion, schlechtes Highlighting, keine intelligenten Hints, etc). Das ist ganz schlecht für C++ Neueinsteiger.
3. Kompatibilität. Viele Libraries machen sich wie gesagt nicht die Mühe den C++ Builder und seine Eigenarten per #ifdef abzudecken.
4. Code Optimierung & Performance des Kompilats hängt anderen Compilern um Jahre hinterher. Das kann grade bei komplexen Berechnungen durchaus einen Unterschied machen.

Und mal speziell im Kontext dieser Masterarbeit: Braucht deine Tochter wirklich eine komplexe GUI? Ein Fenster mit zwei Buttons, das ein Bild anzeigt bekommt man doch selbst mit purer WinAPI in 10 Minuten zusammengebastelt :P

[mensch72]

..."Deshalb noch einmal meine Frage. Habt ihr noch andere Vor- oder Nachteile der beiden Systeme?"...

Du hast ganz richtig erkannt: OutOfTheBox kann man mit C++Builder exakt wie in Delphi per RAD ganz einfach mal eine GUI zusammenklicken und da ganz einfach ein paar C/C++ Sachen aufrufen.

RadStudioPro Enducation kostet fast nix und da ist Delhpi, C++ und Mobile dabei -> kaufen, ansehn und lernen, auch wenn man nix davon laut Lizenz real verwenden darf.

Pures C++ mit externen Libs/Codes im Sinne von Funktionsklassen schreibt man mit VC++, da ist der CodeInsight Editor etwas besser.
Aufrufen, ein paar Optionen einstellen und was anzeigen, das kann man auch mit C++ Builder wo man die in VC bearbeiteten C++ Files 1:1 einbindet. Man sollte sich einfach davor hüten, Delphi VCL&RTL als TList, TStringList oder änlichem in C++ ohne GUI Bezug zu verwenden, denn sowas gibt es woanders nicht.

Ich programmiere Microcontroler nur in "C", da 1:1 abgeleitet mache ich mit C++ Builder auch mal schnell ne GUI wo ich die Datenstrukturen gleich mal 1:1 übernehme. Von C++ nach Delphi geht es einfach wenn man es mal im C++Builder hat, von C++ nach Java oder ObjectiveC geht es fast immer einfach... nach C# und Swift bekommt man fast alles wenn man sich mit Pointern zurückhält.

also nochmal:
- VC++ für pure C++ Funktionsklassen und externen Code ist "der" Standard und die IDE ist gut
- VC++ ist mit C+ wenn es um um C like Sprachen geht auf PC unter Windows der Standard wenn es um echte Programmierung ohne primären GUI Bezug geht
- VisualStudio mit C# und WinForms, .NET / WFC ist der Standard wenn es um aktuelle Windows GUI geht, aber MicroSoft gibt zu 100% auch immer eine aktuelle + gleichwertige C# und C++ Doku&Hilfe

- C++ Builder ist ideal für (schnelle) Projekte, wo man fix mal eine !RAD! GUI mit etwas Embarcadero C++ (GUI)Code macht, um damit die eigentliche Standard C++ Funktionalität aufzurufen und zu nutzen
- Erfahrungen mit C++ Builder interessieren am (Stellen)Markt niemanden, portable Programmierung mit VC++ welche wenn sie am Beispiel mit C++Builder GUI geht wohl auch mit GTK oder XCode GUI geht ist aber sicher ein guter SoftSkill !

[MrSpock]

OK mensch72,

womit machst du die GUI bei VC++, wenn du nicht .NET nutzt? QT?

[jfheins]

Ich habe gerade mal mein VS2013 gestartet und auch nur den Windows-Forms grafischen Designer gefunden. :?
Dagegen kann ich noch halten, dass es (gerade im akademischen Umfeld) oft nicht darauf ankommt, die coolste GUI zu haben. Die Daten müssen halbwegs passend/sinnvoll dargestellt werden.

Und ich kenne jemanden, der macht OpenCV mit Python. Das wäre auch noch eine gute Alternative, weil die Sprache "nett" ist (Speicherverwaltung) und zugleich gute OpenCV-Anbindung hat. DIe Bildverarbeitungsoperationen finden eigentlich alle im optimierten C++ Code statt.

[taveuni]

@Mr Spock: Was ich nich genau verstehe - Wenn Deine Tochter eine Masterarbeit in Bildanalyse mit C++ schreiben will sollte sie doch schon eingermassen sattelfest in Sprache und IDE sein? Oder muss sie erst beides lernen?

[Bernhard Geyer]

Zitat:

Zitat von Zacherl (Beitrag 1320584)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Copy/Move-Semantics-Verstehe ich nicht?

Zu komplex, um das jetzt mit eigenen Worten zu erklären, aber C++ allocated Objekte auf dem Stack und nicht (wie z.b. Delphi) auf dem Heap. Hier hast du jetzt die Möglichkeit Objekte zu "moven" statt zu kopieren. Das hat unter anderem Performance-Vorzüge und ist auch oft semantisch sinnvoll (unique_ptr, etc).
Wenn es dich sehr stark interessiert, dann findest du hier eine ausführliche Erklärung im Rahmen des Copy-Swap-Idioms:
http://stackoverflow.com/a/3279550

Danke, das reicht. Bei mir war nicht mehr auf dem Schirm das es ja auch Sprachen gibt die auch Instanzen von Klassen ohne impliziete Verwendung von new/create/... anlegen können.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Templates - Für was was man mit anderen Sprachfeatures nicht genauso gut lösen kann.

Das Template System ist eine komplette funktionale Programmiersprache, die in C++ eingebettet ist. Normale Generics können hier einpacken und die Delphi Generics erst recht :-D
Sehr mächtig sind auch Template-Spezialisierungen. Grob gesagt hat man ein Grund-Template mit einer bestimmten Signatur und darüber definiert man beliebig viele spezialisierte Templates, die z.b. eine bestimmte Klasse / einen bestimmten Datentyp matchen. Die STL hat beispielsweise eine Art Array Implementation namens std::vector, die man über

Code:

std::vector<int>

deklarieren kann. Wie ein normales Array in Delphi reserviert die Klasse intern dann für jedes Element sizeof(int) an Speicher. Verwendet man aber einen

Code:

std::vector<bool>

nimmt der Compiler das für bool spezialisierte Template und arbeitet intern mit Bitfields, weshalb 8 Werte nicht mehr 8, sondern nur noch 1 Byte belegen.[/QUOTE]
Nochmals Danke. Genau diese Beispiele helfen es klar zu machen wo genau der Vorteil liegt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Und mal speziell im Kontext dieser Masterarbeit: Braucht deine Tochter wirklich eine komplexe GUI? Ein Fenster mit zwei Buttons, das ein Bild anzeigt bekommt man doch selbst mit purer WinAPI in 10 Minuten zusammengebastelt :P

Genau das sollte man hinterfragen. Blos weil (evtl.) eine C-Library helfen könnte heißt es noch nicht das die ganze Lösung in C/C++ realisiert werden müsste.
Hier sind die Vorgaben etwas zu wenig

[MrSpock]

Ich wundere mich ein bischen über die Aussage Visual C++ sei "der" Standard. C++ hat doch einen eigenen Standard, der unabhängig von der IDE ist. Es könnte also bei der Aussage "der" Standard eher um das Framework gehen. Da ist die VCL von Emba ein eigener Weg, aber die MFC auch. Es ist natürlich klar, dass man bei Nutzung von TString oder Tstringlist insbesondere auch außerhalb der GUI sich an den C++ Builder "kettet". Aber bei Nutzung der MFC, von der ich hier gelernt habe, dass sie auch nicht mehr genutzt werden sollte, binde ich mich halt an Visual C++. Ich könnte ja noch Ecplise und "reines" C++ nutzen, müsste dann aber bei der GUI auch wieder ein Framework benutzen. Wenn also Visual C++ "der" Standard ist, welches Framework für C++ ist dann "der" Standard? Ganz interessant finde ich hier diese Übersicht. Hier geht es aber nur um GUI Frameworks. Für die anderen Funkionen nutzt man doch entweder Standardbibliotheken (im Sinne des C++ Standard) oder spezielle Bibliotheken wie z.B. OpenCV, die ich doch dann sowohl in Visual C++, C++ Builder oder Eclipse vewenden kann. Oder wo mache ich hier einen Gedankenfehler? :stupid:

[TiGü]

@MrSpock:

Am Ende würde ich eh das nehmen, was der Betreuer der Masterarbeit vorschlägt!

Wenn der mal das Projekt sich genauer anschauen will, eventuell auch mal zur Fehlerbehebung wenn es klemmt, dann will der sich bestimmt nicht erst mal im C++ Builder einarbeiten, geschweige denn besorgen und installieren!

Der wird höchstwahrscheinlich alle Microsoft-Tools, die man per MSDNAA/BlueSpark-Lizenz bekommen kann, da haben.

Außerdem ist das Argument mit dem Arbeitsmarkt nicht von der Hand zu weisen.
Oder will deine Tochter bei Papi im Betrieb anfangen und Oberflächen im RAD-Stil zusammenklicken?