A
tomasito schrieb:
-Also es gibt die cross-platform Toolkits, die man kostenlos runterladen kann, die aber wohl für meine Windows Anwendung mehr bieten, als ich brauche. Von MFC wurde mir bereits abgeraten.
Qt ist zwar ein Cross-platform-Toolkit, aber sicherlich nicht die schlechteste Wahl. Trolltech hat sich zwischenzeitlich allerhand bei Borland abgeschaut, etwa für ihren Metacompiler das eine oder andere Delphi-Sprachfeature implementiert und einige Ideen und Konzepte aus der VCL übernommen. Das war durchaus keine schlechte Idee - Qt ist wesentlich einfacher zu benutzen als etwa GTK. Wenn es C++ und kostenlos sein muß, ist Qt wohl die beste Lösung.
tomasito schrieb:
-C# scheint das ganze zu vereinfachen, da die .NET umgebung wohl schon sehr viel für die Entwicklung bereitstellt, scheint aber auch von der Performance langsamer zu sein als eine C++ Implementierung?!
Kann man so pauschal nicht sagen. Managed Code kann dank des JIT schneller sein als nativer Code, ist in der Praxis eher etwas langsamer, und im Allgemeinen macht es keinen erwähnenswerten Unterschied. Wenn du eine sehr performancekritische Anwendung hast und mit .NET auf Probleme stößt, hindert dich niemand, Jochens Hinweis zu befolgen, den kritischen Teil in C++ zu schreiben und in eine separate DLL auszulagern - aber das sollte mich doch sehr wundern. Wenn es einen Flaschenhals gibt, ist das in der Regel nicht die .NET-Runtime, sondern entweder ein suboptimaler Algorithmus oder ein grober Verstoß gegen die Konventionen (etwa Stringkonkatenation statt StringBuilder).
Du schreibst, daß du "bereits bestehenden Source Code gebracuhen" könntest - wenn du viel davon hast und nicht auf die Schnelle eine gleichwertige, frei verfügbare Implementierung für .NET findest, bietet es sich eher an, Qt und eine C++-basierte Lösung zu nehmen. Die Bindung von C# nach C++ via C++/CLI, wie von Jochen angeregt, ist möglich, aber auf Dauer etwas lästig.