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 :P

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?

[MrSpock]

Naja, so schlimm ist C++ nicht. Sie muss nicht C++ verwenden, aber er hat von Java abgeraten und es gibt eine große Bibliothek, die wohl in C++ geschrieben ist und die sie verwenden kann. Es geht im Prinzip um Auswertung von bewegten Bildern. Ich muss sie nochmal fragen, ob das Betriebssystem vorgegeben ist, meine aber, dass Windows empfohlen war.

Wenn es hier keine echten Befürworter für den C++ Builder gibt, dann werde ich ihr wohl Visual C++ vorschlagen.

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Naja, so schlimm ist C++ nicht.

Doch, ist es! Musst mich lange genug mit C++ (und dann auch noch mit VS und MFC) herumärgern.
Und wenn es wirklich C++ mit MFC ist dann doppelt beileid.

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Sie muss nicht C++ verwenden, aber er hat von Java abgeraten und es gibt eine große Bibliothek, die wohl in C++ geschrieben ist und die sie verwenden kann.

Notfalls könnte man dies Bibliothek eine C-Like API vergeben um diese dann von Delphi oder per JNI von Java verwenden zu können.
Aber ich kann mir nicht vorstellen das es nicht doch eine Java-Bibliothek gibt die was ähnliches macht.

[taveuni]

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Es geht im Prinzip um Auswertung von bewegten Bildern. Ich muss sie nochmal fragen, ob das Betriebssystem vorgegeben ist, meine aber, dass Windows empfohlen war.

Wow! Bildanalyse aus Videostreams welche über eine triviale Kantendetektion hinausgehen sind meiner Meinung nach etwas vom anspruchvollsten überhaupt. Wir (die Firma in welcher ich arbeite) beschäftigen uns schon seit einiger Zeit damit. Insbesondere wenn dann neuronale Netze dazukommen ist C++ (oder sogar C) beinahe zwingend. Bzw. es vereinfacht die Nutzung der vorhandenen Quellen massiv. Trotzdem ist C vor allem für Neueinsteiger eine Krankheit. Viel Glück Deiner Tochter.

PS: C++ Builder? Lass die Finger davon.

[BUG]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320505)

Und wenn es wirklich C++ mit MFC ist dann doppelt beileid.

Was kann C++ dafür, dass dir eine API von Microsoft nicht gefällt? :stupid:

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320505)

Notfalls könnte man dies Bibliothek eine C-Like API vergeben um diese dann von Delphi oder per JNI von Java verwenden zu können.

Wenn es sich um OpenCV handelt, dann gibt es sogar eine Java-API.
Aber: Wenn der Betreuer von Java abgeraten hat und man C++ beherrscht, dann wäre es dumm Java zu wählen ... schon aus politischer Sicht, aber vielleicht gibt es da am Lehrstuhl auch schon schlechte Erfahrungen.


PS: Ich würde jeden Tag C++ wählen wenn ich sonst in Java programmieren müsste.

[MrSpock]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320505)

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Naja, so schlimm ist C++ nicht.

Doch, ist es! Musst mich lange genug mit C++ (und dann auch noch mit VS und MFC) herumärgern.
Und wenn es wirklich C++ mit MFC ist dann doppelt beileid.

Wenn Sie die Wahl hätte, was würdest du denn als Alternative Programmiersprache und -umgebung empfehlen?

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1320514)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320505)

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Naja, so schlimm ist C++ nicht.

Doch, ist es! Musst mich lange genug mit C++ (und dann auch noch mit VS und MFC) herumärgern.
Und wenn es wirklich C++ mit MFC ist dann doppelt beileid.

Wenn Sie die Wahl hätte, was würdest du denn als Alternative Programmiersprache und -umgebung empfehlen?

Als Primärer Delphianer sicherlich Delphi. Ansonsten Java oder C#.
Von den bisherigen Anforderungen sehe ich (noch nicht) C/C++ als beste Programmiersprache für das Thema.

[TiGü]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320515)

Als Primärer Delphianer sicherlich Delphi. Ansonsten Java oder C#.
Von den bisherigen Anforderungen sehe ich (noch nicht) C/C++ als beste Programmiersprache für das Thema.

Man müsste noch genauer wissen, welche Biblothek verwendet werden soll.
Wenn es, wie BUG schon erwähnte, OpenCV ist, dann wäre doch schon zu C++ anzuraten.
Modernes C++ ist auch einigermaßen anständig.

[Zacherl]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320505)

Zitat:

Zitat von MrSpock (Beitrag 1320484)

Naja, so schlimm ist C++ nicht.

Doch, ist es! Musst mich lange genug mit C++ (und dann auch noch mit VS und MFC) herumärgern.
Und wenn es wirklich C++ mit MFC ist dann doppelt beileid.

Bin ja selbst auch großer Delphi Verfechter seit ewigen Jahren, aber ich musste nach ein paar C++ Projekten feststellen, dass die Sprache einfach 1000-fach überlegen ist. Ich rede jetzt rein von der Sprache (multiple inheritance, GUTES operator overloading, copy / move semantics, templates, ..). Einzig und allein das RAII basierte Exception Handling geht mir vom Konzept her ziemlich gegen den Strich.

Was GUI Entwicklung (welche über 1-2 triviale Formulare hinausgeht) angeht, gebe ich dir aber voll und ganz recht, dass hier C++ nicht umbedingt die optimale Wahl ist. Ich persönlich würde an dieser Stelle immer wieder auf Delphi zurückgreifen (auch wenn mir in letzter Zeit sehr oft C# nahegelegt wurde). Wenn es aber C++ mit komplexer GUI sein soll, dann wird ziemlich oft Qt als gut durchdachtes GUI Framework empfohlen (gibt glaube ich auch einen visuellen Editor).

Zitat:

Zitat von taveuni (Beitrag 1320508)

Trotzdem ist C vor allem für Neueinsteiger eine Krankheit.

Stimmt schon teilweise wegen der neuen Konzepte (RAII, Copy/Move Semantics, etc.), aber man sollte das auch nicht überbewerten. Hier nimmt einem VS bzw. das genannte Resharper Plugin durch die wirklich intelligenten Hinweise allerdings auch einiges an Fehlerquellen weg.

[Rollo62]

Ich habe nichts gegen den BCB, aber leider ist der bei Emba schlecht supportet.
Zwar gibt es noch immer aktuelle Versionen, das ist schonmal super,
aber man kann meines wissens immer nicht einfach VC++ oder Gnu Projekte einfach laden und kompilieren.

Es ist also leider eine Insellösung von der ich nicht ohne weiteres Daten uas der anderen C++ Welt übernehmen kann.
Das ist eigentlich der einzige Grund warum ich damit nichts mehr mache.

Das es eng mit Delphi verbandelt ist spricht eher für BCB.

Von Vorteil könnte es in Zukunft mal werden das Firemonkey nativ auf allen Platformen kompilieren könnte,
(ohne JNI und andere Verrenkungen).
... und was nimmt man da am Besten für eine Sprache ? C++ !

Also Emba: BCB bitte schön weiterpflegen und supporten


Rollo

[BUG]

Zitat:

Zitat von Zacherl (Beitrag 1320519)

Was GUI Entwicklung (welche über 1-2 triviale Formulare hinausgeht) angeht, gebe ich dir aber voll und ganz recht, dass hier C++ nicht umbedingt die optimale Wahl ist.

Jup, aber darum geht es hier afaik nicht.

Andererseits sollte man als Master-Student mithilfe der Betreuer es selbst schaffen das richtige Tool für sich und die Arbeit auszuwählen. Also hab da einfach vertrauen :wink:

[MrSpock]

Nutzt Visual C++ eigentlich das .NET Framework oder MFC ?

[BUG]

Zitat:

Zitat von MrSpock (Beitrag 1320525)

Nutzt Visual C++ eigentlich das .NET Framework oder MFC ?

Für natives C++ braucht man selbst bei Microsoft kein .net. Man muss auch keine MFC verwenden, das ist ja bloß ne Bibliothek.

[uligerhardt]

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. (Und Templates. Da wir noch bei D2007 festhängen, habe ich noch nicht viel Erfahrung mit Delphi-Generics, bin aber trotzdem schon auf einige Einschränkungen gestoßen.)

[MrSpock]

Zitat:

Zitat von BUG (Beitrag 1320528)

Zitat:

Zitat von MrSpock (Beitrag 1320525)

Nutzt Visual C++ eigentlich das .NET Framework oder MFC ?

Für natives C++ braucht man selbst bei Microsoft kein .net. Man muss auch keine MFC verwenden, das ist ja bloß ne Bibliothek.

Visual C++ heißt doch auch, dass eine visuelle Komponentenbibliothek benutzt werden kann und wohl auch für die GUI benutzt wird, oder? Und das wäre dann "normalerweise" die MFC?

[Bernhard Geyer]

Zitat:

Zitat von Zacherl (Beitrag 1320519)

Bin ja selbst auch großer Delphi Verfechter seit ewigen Jahren, aber ich musste nach ein paar C++ Projekten feststellen, dass die Sprache einfach 1000-fach überlegen ist. Ich rede jetzt rein von der Sprache (multiple inheritance, GUTES operator overloading, copy / move semantics, templates, ..). Einzig und allein das RAII basierte Exception Handling geht mir vom Konzept her ziemlich gegen den Strich.

Multiple-Inheritance - Ein glück gibts das nicht. Muss vor Jahren einige Zeit investieren um die Fehler/Probleme bei dieser verwendung zu lösen.
Operation Overloading - OK. Da kann man manchmal ein paar Quellcodezeilen einsparen.
Copy/Move-Semantics-Verstehe ich nicht?
Templates - Für was was man mit anderen Sprachfeatures nicht genauso gut lösen kann.

Zitat:

Zitat von Zacherl (Beitrag 1320519)

Was GUI Entwicklung (welche über 1-2 triviale Formulare hinausgeht) angeht, gebe ich dir aber voll und ganz recht, dass hier C++ nicht umbedingt die optimale Wahl ist. Ich persönlich würde an dieser Stelle immer wieder auf Delphi zurückgreifen (auch wenn mir in letzter Zeit sehr oft C# nahegelegt wurde). Wenn es aber C++ mit komplexer GUI sein soll, dann wird ziemlich oft Qt als gut durchdachtes GUI Framework empfohlen (gibt glaube ich auch einen visuellen Editor).

Bei C++ und GUI ist so das Problem. MFC - Schrott, managed C++ - Wird das aktuell noch gepflegt oder eher wie schon so viele .NET-Ansätze schon wieder legacy. Qt-da bin ich zu weit weg. Kenne mehr oder minder nur den gescheiterten CLX-Ansatz der GUI-Technisch auf QT basierte.

[uligerhardt]

Zitat:

Zitat von MrSpock (Beitrag 1320530)

Visual C++ heißt doch auch, dass eine visuelle Komponentenbibliothek benutzt werden kann und wohl auch für die GUI benutzt wird, oder? Und das wäre dann "normalerweise" die MFC?

Standard in VC++ ist MFC. Ob ein Delphi-Benutzer das als "visual" durchgehen lässt, sei dahingestellt. RAD ist was anderes. :-)
Qt z.B. kann sich aber AFAIK auch recht weitgehend in VC++ integrieren.

[uligerhardt]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Multiple-Inheritance - Ein glück gibts das nicht.

Aaaah! Zum Glück. Zum zum zum :mrgreen:
Mehrfachvererbung kann man sehr wohl sehr nutzbringend verwenden.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Muss vor Jahren einige Zeit investieren um die Fehler/Probleme bei dieser verwendung zu lösen.

Ich muss in dieser Stunde Fehler/Probleme bei der Verwendung von Delphi lösen. Folglich ist Delphi Mist und gehört verboten!!!111!elf!!

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Operation Overloading - OK. Da kann man manchmal ein paar Quellcodezeilen einsparen.

Operatorüberladung ist nicht dazu da, Quellcodezeilen einzusparen, sondern den Code lesbarer zu machen. Etwa

Delphi-Quellcode:

mp := (a + b) / 2;

statt

Delphi-Quellcode:

mp.Assign(a.Plus(b).DivideBy(2));

für Vektoren/Punkte.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

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

Standardbeispiel für Templates/Generics sind Containerklassen. Wie kriegst du die denn ohne T/G genauso gut hin? Cast-Orgien gelten nicht! ;-)

[Bernhard Geyer]

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Multiple-Inheritance - Ein glück gibts das nicht.

Aaaah! Zum Glück. Zum zum zum :mrgreen:
Mehrfachvererbung kann man sehr wohl sehr nutzbringend verwenden.

Ein Spielzeugauto erbt von der klasse und Auto und Spielzeug ...

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Operation Overloading - OK. Da kann man manchmal ein paar Quellcodezeilen einsparen.

Operatorüberladung ist nicht dazu da, Quellcodezeilen einzusparen, sondern den Code lesbarer zu machen. Etwa

Delphi-Quellcode:

mp := (a + b) / 2;

statt

Delphi-Quellcode:

mp.Assign(a.Plus(b).DivideBy(2));

für Vektoren/Punkte.

Ok. Ich bin aber in einem Umfeld untwerwegs bei denen ich das bisher nicht vermisse und auch wenn es dies gäbe auch nicht wüsste wie ich es (bei uns) sinnvoll einsetzen könnte.

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

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

Standardbeispiel für Templates/Generics sind Containerklassen. Wie kriegst du die denn ohne T/G genauso gut hin? Cast-Orgien gelten nicht! ;-)

Du sprachst von Templates. Generics will ich schon behalten. Also was bekommt man mit T besser hin wenn man G hat?

[MrSpock]

So, jetzt hab ich mal VS++ installiert. Offensichtlich habe ich Visual Studio wirklich falsch interpretiert. So etwas wie die VCL hätte ich erwartet, aber nichts dergleichen vorgefunden. Was muss ich denn jetzt noch hinzufügen, um eine RAD Oberfläche zu haben, in der ich insbesondere die GUI schnell erstellen kann. Aber von Delphi bin ich natürlich verwöhnt und möchte auch andere visuelle und nicht-visuelle Komponenten haben. Kann VS das nicht? Wenn nein, warum heißt es dann Visual ... ?:shock:

[uligerhardt]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320543)

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Multiple-Inheritance - Ein glück gibts das nicht.

Aaaah! Zum Glück. Zum zum zum :mrgreen:
Mehrfachvererbung kann man sehr wohl sehr nutzbringend verwenden.

Ein Spielzeugauto erbt von der klasse und Auto und Spielzeug ...

Meine aktiven C++-Zeiten sind leider etwas her. Wir haben aber schon nützlichere Sachen als das damit implementiert. :-)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320543)

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

Operation Overloading - OK. Da kann man manchmal ein paar Quellcodezeilen einsparen.

Operatorüberladung ist nicht dazu da, Quellcodezeilen einzusparen, sondern den Code lesbarer zu machen. Etwa

Delphi-Quellcode:

mp := (a + b) / 2;

statt

Delphi-Quellcode:

mp.Assign(a.Plus(b).DivideBy(2));

für Vektoren/Punkte.

Ok. Ich bin aber in einem Umfeld untwerwegs bei denen ich das bisher nicht vermisse und auch wenn es dies gäbe auch nicht wüsste wie ich es (bei uns) sinnvoll einsetzen könnte.

Naja: Du bist in einem Umfeld unterwegs... das ist jetzt kein gutes Argument. :-P Wir benötigen z.B. viel Geometrie in unseren Programmen, mussten aber "damals" mangels OÜ im a.Plus(b)-Stil arbeiten. Das macht keinen Spaß.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320543)

Zitat:

Zitat von uligerhardt (Beitrag 1320535)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320531)

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

Standardbeispiel für Templates/Generics sind Containerklassen. Wie kriegst du die denn ohne T/G genauso gut hin? Cast-Orgien gelten nicht! ;-)

Du sprachst von Templates. Generics will ich schon behalten. Also was bekommt man mit T besser hin wenn man G hat?

Wie gesagt - meine Generics-Erfahrungen sind eingeschränkt. Z.B. wollte ich als Fingerübung in XE2 einen Unicode-fähigen Ersatz für ShortString und string[N] schreiben. Das wäre mit Templates nicht besonders schwierig gewesen. Mit den Generics von XE2 war das ein Gewürge aus kryptischen Fehlermeldungen und internen Compilerfehlern.

[Bernhard Geyer]

Zitat:

Zitat von uligerhardt (Beitrag 1320548)

Naja: Du bist in einem Umfeld unterwegs... das ist jetzt kein gutes Argument. :-P Wir benötigen z.B. viel Geometrie in unseren Programmen, mussten aber "damals" mangels OÜ im a.Plus(b)-Stil arbeiten. Das macht keinen Spaß.

Das Standardbeispiel ist ja immer irrationale Zahlen oder wirklich Geometrie oder Matrix-Mathematik.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320543)

Wie gesagt - meine Generics-Erfahrungen sind eingeschränkt. Z.B. wollte ich als Fingerübung in XE2 einen Unicode-fähigen Ersatz für ShortString und string[N] schreiben. Das wäre mit Templates nicht besonders schwierig gewesen. Mit den Generics von XE2 war das ein Gewürge aus kryptischen Fehlermeldungen und internen Compilerfehlern.

Ältere XE-Versionen waren aber auch nicht für stabilität im Generic-Umfeld bekannt. Dieses Sprachfeature hat schon ein paar Versionen zum "reifen" gebraucht.

[TiGü]

Zitat:

Zitat von MrSpock (Beitrag 1320545)

Kann VS das nicht? Wenn nein, warum heißt es dann Visual ... ?:shock:

Sagt dir der Begriff WinForms etwas?

Schau dir mal dieses Tutorial an:
http://www.bogotobogo.com/cplusplus/...tudio_2013.php

[MrSpock]

WinForms habe ich nur schonmal als Teil des .NET Frameworks gehört.

Bin dem Link gefolgt und wollte eine CLR Anwendung gemäß Anweisung erstellen, dann kam dieser Fehler.

Zitat:

bei Microsoft.VisualStudio.Designer.Interfaces.IVSMDCo deDomProvider.get_CodeDomProvider()
bei Microsoft.VisualStudio.Shell.Design.Serialization. CodeDom.CodeDomDocDataAdapter.get_Provider()
bei Microsoft.VisualStudio.Shell.Design.Serialization. CodeDom.CodeDomDocDataAdapter.get_CompileUnit()
bei Microsoft.VisualStudio.Design.Serialization.CodeDo m.VSCodeDomDesignerLoader.PerformLoad(IDesignerSer ializationManager serializationManager)
bei Microsoft.VisualStudio.Design.Serialization.CodeDo m.VSCodeDomDesignerLoader.DeferredLoadHandler.Micr osoft.VisualStudio.TextManager.Interop.IVsTextBuff erDataEvents.OnLoadCompleted(Int32 fReload)

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