C++ Builder oder Visual C++

[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

[Sir Rufo]

Da ja wohl alles egal ist bis auf C++ scheint wohl auch die GUI entweder absolut sekundär oder gänzlich unnötig sein.

Bei der Bild-Verarbeitung brauche ich auch keine GUI (was will ich denn während der Verarbeitung sehen - ein animiertes Bild?).

[MrSpock]

Die GUI spielt definitiv eine untergeordnete Rolle.

Sie wird ihr Programm vorführen müssen und die Algorithmen an einigen Beispielvideos demonstrieren müssen. Aber sie kann das von Ihrem Rechner aus machen.