C++ Builder oder Visual C++

[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?

[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?

[TiGü]

Zitat von MrSpock:

Ich wundere mich ein bischen über die Aussage Visual C++ sei "der" Standard.

Hier meinen wir (auch) die IDE/Umgebung und nicht nur die Sprache.

Recherchiere doch mal in größeren IT-lastigen Jobbörsen (Stepstone, Monster, Heise, careers.stackoverflow.com), was der Markt gerade so möchte.

[Zacherl]

Zitat von MrSpock:

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?

Sagen wir mal so: Die "richtig großen" Libs werden in der Regel kompatibel zu ziemlich allen C++ Compilern sein. Ob das bei OpenCV jetzt für C++ Builder auch der Fall ist, müsste man einfach nachschauen oder testen. Bei kleinen Libs ist das ganz oft aber nicht der Fall. Man darf nicht vergessen, dass eine Lib nicht nur aus den Binärdateien besteht (die theoretisch immer kompatibel sein sollten), sondern auch aus Header Files (und genau hier gibt es dann die Kompatibilitätsprobleme).

[MrSpock]

Zitat von Zacherl:

... Bei kleinen Libs ist das ganz oft aber nicht der Fall. Man darf nicht vergessen, dass eine Lib nicht nur aus den Binärdateien besteht (die theoretisch immer kompatibel sein sollten), sondern auch aus Header Files (und genau hier gibt es dann die Kompatibilitätsprobleme).

Warum sind z.B. Headerfiles nicht kompatibel? Weil es dort Deklarationen gibt, die in systemspezifischen Bilbliotheken definiert sind?

[BUG]

Zitat von MrSpock:

Warum sind z.B. Headerfiles nicht kompatibel? Weil es dort Deklarationen gibt, die in systemspezifischen Bilbliotheken definiert sind?

Die Verwendeten Bibliotheken müssen natürlich da sein; aber es gibt da noch Compiler-spezifische Erweiterung wie zum Beispiel Pragmas und einige Attribute.
Zusätzlich ist zum Beispiel der Microsoft-Compiler sehr gutmütig mit einigen nicht-Standard-konformen Konstrukten ... da macht Portieren dann Spaß

[Zacherl]

Zitat von MrSpock:

Zitat von Zacherl:

... Bei kleinen Libs ist das ganz oft aber nicht der Fall. Man darf nicht vergessen, dass eine Lib nicht nur aus den Binärdateien besteht (die theoretisch immer kompatibel sein sollten), sondern auch aus Header Files (und genau hier gibt es dann die Kompatibilitätsprobleme).

Warum sind z.B. Headerfiles nicht kompatibel? Weil es dort Deklarationen gibt, die in systemspezifischen Bilbliotheken definiert sind?

Header-Files können unter anderem auch (anders als beim Delphi Interface-Teil) richtigen Code in Form von Funktionen, oder inline deklarierten Klassenmethoden enthalten. Diese Komponenten sind nicht im Binärteil von bereits kompilierten Libs enthalten und werden dann on-demand erstellt. Je nach Compiler variieren auch Sprachfeatures, weshalb ein Header dann unter einem Compiler wunderbar verwendet werden kann, für einen Anderen aber erst angepasst werden muss.

Teilweise muss man einige Verrenkungen anstellen, damit eine Lib zu allen großen Compilern kompatibel ist. Kleines Beispiel:

Code:

#if defined(MYLIB_MSVC) || defined(MYLIB_BORLAND)
#   define MYLIB_INLINE __inline 
#else
#   define MYLIB_INLINE inline
#endif

oder auch:

Code:

#if defined (_M_AMD64) || defined (__x86_64__)
#   define MYLIB_X64
#elif defined (_M_IX86) || defined (__i386__)
#   define MYLIB_X86
#else
#   error "Unsupported architecture detected"
#endif