Fragen zu DLL WINAPI CLI
-
Hallo, ich habe ein paar allgemeine Frage, ich baue mir gerade einen Algorythmus, incl. Programm (zum generieren). Beitrag dazu hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-200153.html
Ich habe mir folgendes überlegt, das ganze in eine dll-datei auszu lagern (die funktionen für den Algorythmus). Nun habe ich aber ein paar kleine Probleme.
Nur zu Info ich habe noch nie mit dlls gearbeitet und wollte mich da mal ein arbeiten.
1. Was bringt mir die Auslagerung in eine dll-file.
2. Was ist sinnvoller DLL oder Static library.Da wäre zum Thema DLL.
Für das Generationsprogramm verwende ich derzeit C++/CLI, ist atm das einzigste was ich kann. Nur bekomme ich da immer eine Kriese mit dem Code :), es gefällt mir einfach nicht und ich habe immer Progleme mit dem konvertieren von string^ zu int oder char.... ( was aber an mangeldem wissen liegt
) Das nervt mich etwas. Ich habe mir überlegt auf rein WINAPI umzusteigen. Nun würde ich halt gerne mal wissen ob das vor oder nachteile hat... Habe jetzt über beide sachen was gelsen auch etwas rumgespielt, das einzigste was ich erkennen konnte war:CLI: Gui in 1min erstellt mit schnick-schnack durch den bei VC++ integrierten Designer
WINAPI: der Code ist mehr oder weniger Easy-Going nachvollziehbar.
MFC: Habe ich mir auch duchgelesen und angeschaut, jedoch habe ich da irgendwie keine Meinung....
Das Problem ist einfach, ich weiß nicht was ich wann einsetzen soll, da mir einfach die Erfahrung fehlt. Mit CLI komme ich zwar gut klar nur finde ich es halt etwas blöd, was das zusammen-klatsch von Managed- und Unmanaged Code angeht.
Würde mich über ein paar Tipps freuen.
so long
jd
-
Zum einen, keine der Fragen gehört in das ANSI C++ Forum, sowohl für C++/CLI, WinAPI als auch MFC existieren passende Unterforen.
jd schrieb:
Nur zu Info ich habe noch nie mit dlls gearbeitet und wollte mich da mal ein arbeiten.
1. Was bringt mir die Auslagerung in eine dll-file.
2. Was ist sinnvoller DLL oder Static library.Da wäre zum Thema DLL.
Was bring allgemein gesprochen eine Auslagerung in eine Bibliothek?
- Möglichkeit der Trennung von logischen oder fachlichen Bereichen
- Übersichtlichere Codemodule, da immer nur auf einen Teil gearbeitet wirdDynamisch gegenüber statisch gebundenen Bibliotheken haben den Vorteil das wenn sie von mehreren Programmen verwendet werden nur einmal im Speicher liegen und zur Laufzeit gebunden werden können (z.B. Pluginschnittstellen...). Statisch gebundene müssten aber etwas schnellere Aufrufe ermöglichen.
jd schrieb:
Für das Generationsprogramm verwende ich derzeit C++/CLI, ist atm das einzigste was ich kann. Nur bekomme ich da immer eine Kriese mit dem Code :), es gefällt mir einfach nicht und ich habe immer Progleme mit dem konvertieren von string^ zu int oder char.... ( was aber an mangeldem wissen liegt
)Darf ich mal fragen wo du damit Probleme hast, bzw. warum du z.B. in char konvertieren willst? Für Konvertierungen vom String in andere Typen hat das .Net Framework aber wirklich genug Möglichkeiten.
jd schrieb:
Das nervt mich etwas. Ich habe mir überlegt auf rein WINAPI umzusteigen. Nun würde ich halt gerne mal wissen ob das vor oder nachteile hat... Habe jetzt über beide sachen was gelsen auch etwas rumgespielt, das einzigste was ich erkennen konnte war:
CLI: Gui in 1min erstellt mit schnick-schnack durch den bei VC++ integrierten Designer
WINAPI: der Code ist mehr oder weniger Easy-Going nachvollziehbar.
Nachteil an der WinAPI: fehlende Typsicherheit, keine OO und sehr viel Zeigerarithmetik die man sich lieber sparen sollte ;p
C++/CLI kann man auch rein über Code programmieren, und die GUI ist damit ebenso nachvollziehbar. Das es kryptische Sprachelemente gibt, liegt daran das es eine Mischung zwischen Managed und unmanaged ist (Ich persönlich ziehe aber lieber entweder C++ oder C# vor, je nach Anwendungsfall).
jd schrieb:
MFC: Habe ich mir auch duchgelesen und angeschaut, jedoch habe ich da irgendwie keine Meinung....
MFC ist ein mehr schlecht als rechter OO-Aufsatz auf die WinAPI, wobei man bei komplexeren Anwendungen mit Sicherheit mit der MFC weiter und schneller vorankommt als mit der Windows API. Man sieht der MFC an das sie schon recht alt ist, auch wenn sie immer noch kleinere Aktualisierungen bekommt.
jd schrieb:
Das Problem ist einfach, ich weiß nicht was ich wann einsetzen soll, da mir einfach die Erfahrung fehlt. Mit CLI komme ich zwar gut klar nur finde ich es halt etwas blöd, was das zusammen-klatsch von Managed- und Unmanaged Code angeht.
Dann steig auf etwas anderes um, es gibt mehr als eine Alternative, die Windows API sehe ich aber noch als das schlechteste daran an, wenn deine Anwendungen auch mal mehr als ein, zwei Fenster haben soll.
Es gibt auch außer der MFC noch diverse andere GUI-Frameworks für C++ (z.B. QT, wxWindows...), die MFC war und ist nur unter Windows und C++ wohl noch die üblichste.
Die nächste Option ist natürlich bei managed Code zu bleiben und zu C# zu wechseln.
cu André
-
asc schrieb:
Zum einen, keine der Fragen gehört in das ANSI C++ Forum, sowohl für C++/CLI, WinAPI als auch MFC existieren passende Unterforen.
Ich weiß, wollte aber nicht 3 verschiedene Themen auf machen, also habe ich mich für die C++ Abteilung entschieden

Danke für deine genau Antwort, jetzt komme ich schon ein stück weiter.
Also ich habe mich bis jetzt so entschieden das ich WINAPI sein lasse
und entweder auf CLI oder auf MFC gehe. Du sagtest ja das MFC relativ halt ist und nur kleine änderungen bekommt ist das ein nachteil? Weil MFC setzt doch eigentlich auf WINAPI auf und Kapselt das ganze in OOP oder irre ich mich da jetzt. Wieso empfielst du für CLI ehr C#? wxWidgets habe ich mir auch mal angeschaut, aber dem traue ich nicht ganz über den Weg, da ich meine .libs selber kompilieren muss (laut Anleitung), naja das verschaft mir mehr oder weniger ein misstrauen. QT schau ich mir mal an eventuell kann ich mich damit anfreunden.so long
jd
-
jd schrieb:
Ich weiß, wollte aber nicht 3 verschiedene Themen auf machen, also habe ich mich für die C++ Abteilung entschieden

Nur das es in einer ANSI C++ Abteilung wirklich nicht hingehört

jd schrieb:
Also ich habe mich bis jetzt so entschieden das ich WINAPI sein lasse
und entweder auf CLI oder auf MFC gehe. Du sagtest ja das MFC relativ halt ist und nur kleine änderungen bekommt ist das ein nachteil? Weil MFC setzt doch eigentlich auf WINAPI auf und Kapselt das ganze in OOP oder irre ich mich da jetzt.Microsoft hat die MFC zwar nicht eingestellt, aber favorisiert das .Net Framework (Windows Forms, oder aktueller WPF - Windows Presentation Foundation), was man auch bei der Weiterentwicklung bemerkt. Es ranken sich immer wieder Gerüchte das die MFC-Entwicklung eingestellt wird, aber ich schätze aufgrund der Kunden haben sie immer wieder ein paar Aktualisierungen gemacht.
jd schrieb:
Wieso empfielst du für CLI ehr C#?
Zum einen trenne dich von dem CLI Begriff für Oberflächen. C++/CLI setzt in der Regel bei Oberflächen auf Windows Forms, das CLI steht nicht für die Oberflächen sondern ausschließlich für die Erweiterung von C++ um die Managed Bestandteile.
Zum Anderen: C++/CLI spielt seine Stärken vorwiegend in den Bereichen aus, in denen unmanaged Code mit managed Code kombiniert werden soll. Da das .Net Framework (wozu Windows Forms gehört) aber besser von C# und Visual Basic unterstüzt wird, rate ich hier für Oberflächen halt eher zu C#. Die aktuellste .Net GUI (WPF) wirst du unter C++/CLI auch nur ausschließlich über Code verwenden, da C++/CLI (noch) keine partitiellen Klassen unterstüzt, C#/VB aber schon.
Wenn schon .Net, dann möglichst lieber C#.
Was ist nun der Vorteil oder Nachteil von C#/.Net gegenüber C++ und irgendeiner anderen GUI?
- Grundsätzlich ist managed Code etwas langsamer als nativer Code, auch wenn Microsoft Mechanismen eingebaut hat die das Problem etwas beheben und theoretisch sogar in Teilen schneller ablaufen kann (Da der "echte" Code erst bei der Ausführung generiert wird, können sie diesen speziell für die Plattform optimieren; Aber nichts desto trotz muss er immer zumindest einmal generiert werden beim Start; Wenn Code mehrfach durchlaufen wird, greift dieser auf den bereits übersetzten Code zurück).
- .Net unterstüzt den Sprach und DLL-Übergreifenden Export von Klassen, dies geht soweit das eine in VB geschriebene Klasse nicht nur in C# funktioniert, sondern zudem auch als Basisklasse für eine C# (oder managed C++/CLI) Klasse dienen kann.
- .Net liefert ein mächtiges Framework mit, das von Filehandling, über Sicherheitsmechanismen bis hin zur GUI alles abdeckt.
- Ein unter .Net geschriebenes Programm kann nur ausgeführt werden, wenn auf dem Zielrechner das entsprechende .Net Framework läuft.
- .Net ist ähnlich wie die Windows API und auch die MFC nicht portabel und (fast) nur unter der Windowsplattform lauffähig, auch wenn es einige Projekte gibt, die dies mehr oder weniger auch für andere Plattformen umgesetzt haben (Berühmtestes Beispiel ist das Mono Projekt).jd schrieb:
wxWidgets habe ich mir auch mal angeschaut, aber dem traue ich nicht ganz über den Weg, da ich meine .libs selber kompilieren muss (laut Anleitung), naja das verschaft mir mehr oder weniger ein misstrauen. QT schau ich mir mal an eventuell kann ich mich damit anfreunden.
wxWidgets und QT haben den Vorteil Plattformunabhängig zu sein, wobei QT imho das mächtigere ist (und auch mehr als GUI abdeckt), aber kostenlos nur Open Source Programme erlaubt und dich in der Wahl des Compilers einschränkt, die kostenpflichtige Version ist für den Privatentwickler nicht wirklich erschwinglich und liegt im 4 Stelligen Eurobereich.
cu André
-
Dieser Thread wurde von Moderator/in CStoll aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.