Ich schreibe eine kleine App, die ein paar Listenfelder, Schaltflächen, Textfelder erfordert. Es wird mit Boost, MySQL, etc. C ++ statischen Bibliotheken verknüpft. Das Projekt benötigt win32-Funktionen. Ich denke, Winforms wird in Ordnung sein (MFC und CodeJock benötigen zu viel Zeit).
So scheint C ++ / CLI perfekt für den Job zu sein. Verwenden Sie einfach Standard C ++ neben der GUI. Dann laufe ich über Threads, die vorschlagen, dass Sie Ihre GUI in C # stattdessen schreiben. Dann verwenden Sie p / Invoke (langsam) oder eine C ++ / CLI-Schnittstelle zu Ihren Standard-C ++ - DLLs.
Beispiel: Ссылка
Warum? Welchen Vorteil hat die Verwendung von C # für Ihre WinForms GUI anstelle von C ++ / CLI (sie sehen gleich aus, die Befehle sind gleich). Welchen Nachteil gibt es bei der Verwendung von C ++ / CLI ausführbaren anstelle von Standard-C ++ - ausführbaren Dateien. Ich kann verstehen, ob die plattformübergreifende Kompatibilität ein Problem war, aber dann könnten Sie einfach keine verwalteten Funktionen (außer der GUI) verwenden.
Ich verstehe nicht, warum Sie C # verwenden würden, und dann gehen Sie so weit, um es mit einer "Engine-DLL" zu trennen. Es sei denn natürlich die "Engine DLL" wurde auch für andere Anwendungen verwendet.
Danke
Ich denke, die meisten Empfehlungen in Bezug auf diese Frage drehen sich um die Tatsache, dass C # nur eine bessere Umgebung zum Erstellen von .NET-Anwendungen als C ++ / CLI ist. Die Syntax ist sauberer, das Tooling ist besser - sowohl in Visual Studio als auch von Drittanbietern. Sie werden mehr und besseren Support von Entwicklern bekommen, die fast alle besser mit C # vertraut sind.
C ++ / CLI-Anwendungen unterscheiden sich von Standard-C ++ mit all den ^ und% -Zeichen, die ich zumindest für NICHT C ++ halte.
Die meisten Ratschläge stammen auch aus der Sicht, dass Sie eine .NET-Anwendung erstellen möchten und C ++ / CLI eher als Klebeschicht verwendet wird. Wann immer ich C ++ / CLI verwendet habe, war es widerwillig und fast immer, weil einige Bibliotheken von Drittanbietern viele komplexe C / C ++ - Objekte hatten, die sie weitergegeben hat. Wenn Sie C # und P / Invoke verwenden, müssen Sie häufig Klassen erstellen, um die Strukturen und Klassen in den C ++ - Headerdateien der Software zu spiegeln, mit der Sie interagieren. Diese synchron zu halten ist arbeitsintensiv und es ist leicht, Fehler zu machen. Wenn Sie herausfinden, wie man eine Struktur mit Zeigern auf Structures von Arrays von Struct marshaliert, wird Ihr Gehirn schmelzen!
Mein allgemeiner Rat ist, C # (oder VB.NET) zu verwenden, um so viel Code wie möglich für Ihre Anwendung zu erstellen. Verwenden Sie P / Invoke, wenn Sie die Win32-API und / oder Drittanbieter-SDKs aufrufen müssen und die Schnittstellen und Parameter einfach sind. Verwenden Sie C ++ / CLI als Klebeschicht, wenn dies nicht möglich ist.
In einer Teamumgebung werden sich Ihre Mitentwickler dafür bedanken, dass Sie Ihre Verwendung von C ++ / CLI nur dort eingeschränkt haben, wo sie unbedingt erforderlich ist. C ++ / CLI-Expertise ist einfach nicht üblich.
Ich persönlich liebe C ++ / CLI, aber ich würde meine Benutzeroberfläche immer noch lieber in C # schreiben.
C ++ / CLI ist großartig , um direkt mit Win32 zu arbeiten oder mit altem Code zu kommunizieren, aber es ist ein wenig zu ausführlich für meinen Geschmack, wenn es um UI-Code geht. WinForms UI-Code in C # ist nett und einfach (in den meisten Fällen, haha). Das Schreiben von UI-Code in C ++ ist fast immer unordentlich (schau dir einfach MFC an).
Warum erstellen Sie nicht einfach Ihre UI in einer C # -Assembly und fügen Ihren gesamten untergeordneten Code in eine C ++ / CLI-Assembly ein? Das Schöne an C ++ / CLI ist, dass Sie eine verwaltete Schicht erstellen können, die Ihr C # -Code leicht aufrufen kann. Diese verwaltete Schicht kann dann Anrufe auf einfache Weise an eine native Schicht aus reinem C ++ - oder C-Code weiterleiten.
Welchen Vorteil hat C #? für Ihre winforms GUI statt C ++ / CLI (sie sehen gleich aus, die Befehle sind gleich)?
Sie sehen nicht gleich aus. C # ist meiner Meinung nach sauberer und hat einige nützliche Abstraktionen. Tooling-Unterstützung ist auch für C # oder VB.net massiv besser.
Hier finden Sie einen Beispielvergleich
Und vergessen Sie nicht produktive Sprachfunktionen wie Lambda Expressions, LINQ, Typ-Inferenz usw., die C # zuerst treffen und auf VB.net herunterrasen, aber selten den Weg nach C ++ / CLI finden.
Ich habe mich gefragt, weshalb ich mit Visual Studio 2008 ein neues Windows Forms-Anwendungsprojekt mit C ++ / CLI als Sprache erstellt habe. Das erste, was es getan hat, ist einen Fehler zu erzeugen. Also habe ich das als Hinweis genommen, dass dieses Zeug nicht ganz einsatzbereit ist. Vielleicht gebe ich es nicht genug von einer Chance!
%Vor%
Dies passiert, wenn ich versuche, die vom Assistenten erstellte Datei Form1.h zu öffnen.
Ich schreibe eine kleine App, die ein paar Listenfelder, Schaltflächen, Textfelder erfordert. Es wird mit Boost, MySQL, etc. C ++ statischen Bibliotheken verknüpft. Das Projekt benötigt win32 Funktionen ...
Ich bekomme wahrscheinlich das Risiko, downvoted zu werden, aber wenn der meiste Code bereits in C ++ geschrieben ist und verwenden Sie die C ++ - Funktionalität. Wäre es nicht einfacher, Ihre GUI in Native C ++ zu schreiben.
Sie müssen MFC nicht zum Erstellen einer GUI verwenden. Schauen Sie sich Qt4 an, sie haben ein sehr gutes Tutorial So können Sie innerhalb weniger Stunden mit dem Schreiben von GUI in C ++ beginnen.
Ja, es scheint, dass die meisten Leute automatisch vorschlagen, C # über C ++ zu verwenden, vorausgesetzt, Sie kennen C # bereits oder sind bereit, Zeit in das Lernen zu investieren. Ich sehe nicht den ganzen Hass auf C ++ / CLI WinForms. Zumindest, wenn Sie über vorhandenen C ++ Code portieren wollen, wird die Arbeit erledigt. Zumindest habe ich auf einer GUI an meine bestehende C ++ mit WinForms / CLI angeheftet. Ja, ich benutze wahrscheinlich C #, wenn ich von vorne anfange seit:
Aber wie ich schon sagte, wenn Sie bereits den C ++ - Code haben, wollen Sie wirklich von vorne anfangen?
Tags und Links c# user-interface windows c++-cli