C++ Builder oder Visual C++

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

[Alfredo]

Zitat von MrSpock:

Aber sie kann das von Ihrem Rechner aus machen.

Du solltest testen ob der Vorführrechner genügend Power(Prozessor, RAM und Graphikkarte) und die richtige Festplatte
(Standardplatten ruckeln im Videobereich) hat.

Mulitprozessorprogrammierung wegen Laufzeit der Programme erforderlich?

Gruß
Alfred

[MrSpock]

Ob der Rechner leistungsfähig genug ist, muss sie noch prüfen.

Hab jetzt einmal OpenCV geladen und in C++ Builder eine einfache Anwendung aus dem Tutorial übermnommen. Beim Compilieren erhalte ich dann eine Fehlermeldung bei:

Code:

namespace cv
{
    using std::min;
    using std::max;
    using std::abs;
    using std::swap;
    using std::sqrt; << hier kommt der Fehler

Zitat:

[BCC32 Fehler] cvstd.hpp(74): E2316 '_fm_sqrt' ist kein Member von 'std'
Vollständiger Parser-Kontext
File1.cpp(9): #include C:\Daten\Cpp\opencv\sources\include\opencv\cv.h
cv.h(63): #include C:\Daten\Cpp\opencv\build\include\opencv2/core/core_c.h
core_c.h(48): #include C:\Daten\Cpp\opencv\build\include\opencv2/core/types_c.h
types_c.h(101): #include C:\Daten\Cpp\opencv\build\include\opencv2/core.hpp
core.hpp(54): #include C:\Daten\Cpp\opencv\build\include\opencv2/core/base.hpp
base.hpp(55): #include C:\Daten\Cpp\opencv\build\include\opencv2/core/cvstd.hpp
cvstd.hpp(69): namespace cv

Das könnte jetzt eine "Inkompatibilität" des Header Files sein, was hier angesprochen wurde?!

[BUG]

Irgendwo wird fastmath.h eingebunden, das durch ein Präprozessormakro sqrt durch _fm_sqrt ersetzt; das ist natürlich keine gute Idee. Das das Teil von Compilerhersteller kommt macht es irgendwie schlimmer

[MrSpock]

Zitat von BUG:

Irgendwo wird fastmath.h eingebunden, das durch ein Präprozessormakro sqrt durch _fm_sqrt ersetzt; das ist natürlich keine gute Idee. Das das Teil von Compilerhersteller kommt macht es irgendwie schlimmer

OK, habe die Option, die dort zum Verhindern der Umwandlung gesetzt werden kann, geändert und dann hat es wieder weiter compiliert, ist aber an zwei Stellen wieder auf Fehler gelaufen.

Werde es jetzt mal mit VC++ versuchen.

[Mikkey]

Da ich in der letzten Zeit relativ viel mit dem C++-Builder (aus XE7) gemacht habe und einiges an Erfahrung mit MS-C++ habe, gebe ich meinen Senf auch noch dazu.

Die Emba-IDE ist verglichen mit Visual Studio (und auch "SharpDevelop") >5 Jahre zurück. Wie schon geschrieben, ein einzelner Syntaxfehler in irgendeiner Datei des Projekts verhindert die Anzeige der Klassenmember.

Der C++-Builder gibt Fehlermeldungen, die den Fehler nicht richtig beschreiben, verlagert den Ort der Fehler zum Teil in andere Quelldateien.

Für mich das schlimmste: Ebenso wie bei Delphi erlaubt der Compiler das Erstellen von Klassen mit pure-virtuellen Funktionen. In dem Zusammenhang eine ungewöhnliche Handhabung bei Interfaces - der Compiler gibt nicht mal einen Hinweis aus, dass eine Funktion nicht implementiert wurde, sie wird stillschweigend als pure-virtual eingebaut.

Bei Controls hat Delphi die Nase vorn, die Menge an Standardcontrols ist bei Microsoft ziemlich beschränkt (das gilt dort für C# gleichermaßen). So etwas wie TChart muss man sich dort selbst machen.

Edit: Weiteres Manko beim C++-Builder ist, dass der 64-Bit-Compiler Buggy ist, zum Teil werden kryptische Fehlermeldungen ausgegeben, obwohl der Code absolut in Ordnung ist (gem. 32-Bit-Compiler).

[Der schöne Günther]

( Mit dem LLVM-Compiler habe ich leider noch nicht wirklich produktiv etwas gemacht, aber spontan sah es mir auch danach aus als könne man mit den Fehlermeldungen noch weniger anfangen als sonst. Konkrete Beispiele habe ich aber nicht mehr zur Hand. )

[Zacherl]

Zitat von Mikkey:

Für mich das schlimmste: Ebenso wie bei Delphi erlaubt der Compiler das Erstellen von Klassen mit pure-virtuellen Funktionen. In dem Zusammenhang eine ungewöhnliche Handhabung bei Interfaces - der Compiler gibt nicht mal einen Hinweis aus, dass eine Funktion nicht implementiert wurde, sie wird stillschweigend als pure-virtual eingebaut.

gut zu wissen. Das habe ich bisher tatsächlich bei keinem anderen C++ Compiler gesehen.

Zitat von Der schöne Günther:

( Mit dem LLVM-Compiler habe ich leider noch nicht wirklich produktiv etwas gemacht, aber spontan sah es mir auch danach aus als könne man mit den Fehlermeldungen noch weniger anfangen als sonst. Konkrete Beispiele habe ich aber nicht mehr zur Hand. )

Habe ich eigentlich eher gegenteilig in Erinnerung. Zumindest bei komplexem Template Code sind die Fehlermeldungen von MSVC oftmals nicht sehr konkret. Da hat LLVM/CLang teilweise bessere Sachen ausgespuckt.
Der LLVM Compiler ist aber recht umständlich zum Laufen zu bekommen (zumindest unter Windows mit Visual Studio).

[BUG]

OT:

Zitat von Zacherl:

Der LLVM Compiler ist aber recht umständlich zum Laufen zu bekommen (zumindest unter Windows mit Visual Studio).

Wenn ich mal wieder etwas mehr Zeit habe, werde ich CLion antesten. Was ich bis jetzt gesehen habe sieht ziemlich vielversprechend aus.