Meinung gefragt...Visual Component Framework
-
Vielen dank, aber ich bin noch etwas unentschlossen.die
wxWidgets gefallen mir von C++ Style zum teil nich so sehr.
Zu viele Makros, keine Templates, usw. Eben kein wirklich
modernes C++, eher so C/C++ wischi-waschi!ich suche etwas
das etwas so konsequent mit c++ arbeitet wie die boost-library,
das würde mir gefallen
-
Ich gucke mich auch nach einer modernen GUI Lib um. Aber entweder unterstützen die keine nativen Widgets, oder sind veraltet:
http://kharchi.de/cpp_gui/index.html
-
das ist mein Problem!
-
Ja, das ist tatsächlich ein Problem... jedoch nur, wenn man Multiplattform programmieren will. Für Windows ist das ja kein Problem, da ist SmartWin++ auf jeden Fall nett.
Ansonst kann ich nur sagen, das ich zur Zeit an einem GUI-Toolkit arbeite, das sowohl native Widgets als auch vernünftiges C++ nutzt. Das ganze ist dann auch plattformneutral. Ist aber noch nicht wirklich brauchbar, vom Funktionsumfang... sonst hätte ich es schon online gestellt.
Kann daher nur empfehlen einen Kompromiss einzugehen und eine Lib zu wählen, die an einer Stelle halt nicht den Wunsch erfüllt. Sonst kommt man nie in die Pötte.
-
Ah, SmartWin++ sieht ja wirklich interessant aus. Der Code wirkt auch sehr übersichtlich und modern. Jedoch will ich ungerne auf die erweiterten Fähigkeiten von z.B. wxWidgets verzichten (z.B. Sockets), das ja SmartWin++ leider nicht anbietet. Gehört es zum schlechten Stil, zwei verschiedene Bibliotheken in einem Projekt gemeinsam zu verwenden (SmartWin für GUI, und wx für Sockets etc.)?
-
Ist möglich, gibt ja auch wxWidgets in der non-gui Version.
Und was sockets angeht, ist boost::asio einen Blick wert.
-
Was willst du denn? Eine GUI-Library oder ein Anwendungs-Framework? Das sind schon zwei verschiedene paar Schuhe! SmartWin ist ein GUI-Library - nicht mehr und nicht weniger.
wxWidgets ist dagegen ein Anwendungs-Framework. Ein gaaanz anderes Ziel wird dort verfolgt. Du kannst natürlich Klassen aus unterschiedlichen Libraries nutzen. Immerhin ist wxWidgets serviceorientiert - also in mehrere Libs aufgeteilt. Du nimmst das, was dir gefällt. Was du nichts brauchst, lässt du weg.
Wobei ich nicht weiß, warum man wxSockets benutzen muß, wenn es z.B. Boost.asio mittlerweile gibt.
-
phlox81 schrieb:
Und was sockets angeht, ist boost::asio einen Blick wert.
Danke für den Hinweis. Wusste bis jetzt nichts davon.
Artchi schrieb:
Was willst du denn? Eine GUI-Library oder ein Anwendungs-Framework?
Wie schon gesagt, ich möchte ein Anwendungsframework in modernem C++ Design, und mit Unterstützung von nativen Widgets, aber das gibt es leider nicht. (Ausgenommen VCF, aber da habe ich auch nichts positives gehört)
Dann werde ich mir boost::asio mal angucken.
-
am liebsten wäre mir ein schönes GUI-Toolkit im Boost-style
was sich auch in selbiges gut integrieren lässt.*Träum*
-
Hi, ich habe mal eine Frage, meint ihr mit Makros dieses "#define a(x, y) x * y; y + 3;" ?
Was ist denn daran so schlimm, wenn du verwendet werden?
Sind die langsamer.. oder weshalb wollt ihr die nicht?
-
Ja, sind diese #define-Dinger. Das Thema haben wir im C++-Forum jede Woche. Kurz gesagt: "Makros are evil!"
Also, sie sind kein Sprachbestandteil des C++-Compilers. Sie sind eine "dumme" Textersetzungsfunktion durch den Präprozessor. D.h. der Compiler sieht diese Makros nicht. Entsprechend kann ein Makro Fehler hervorrufen, die man durch den Compiler angemeckert bekommt, die man im Source aber schlecht nachvollziehen kann. Debuggen ist sogar ganz schlecht möglich.
Außerdem sind Makros schlecht für IDEs, weil die C++-Tools mit Makros auch schlechter umgehen können. Ist alles viel zu aufwändig, für die Tool-Entwickler.
Es gibt gaaaanz wenige Ausnahmen, wo Makros nicht durch C++-Code (sinnvoll) ersetzbar sind. Aber das trifft ganz bestimmt nicht auf GUI-Libraries zu.
-
Artchi schrieb:
Es gibt gaaaanz wenige Ausnahmen, wo Makros nicht durch C++-Code (sinnvoll) ersetzbar sind. Aber das trifft ganz bestimmt nicht auf GUI-Libraries zu.
wäre sowas eine dieser gaaaaanz wenigen Ausnahmen?
#ifdef _MSC_VER #define __property(n,g,s) __declspec(property(get=g,put=s))n #define __propertySet(n,s) __declspec(property(put=s))n #define __propertyGet(n,s) __declspec(property(get=s))n #endif #ifdef __BCPLUSPLUS__ #define __property(n,g,s) __property n = {read=g,write=s} #define __propertySet(n,s) __property n = {write=s} #define __propertyGet(n,g) __property n = {read=g} #endif