Netzwerkprogrammierung: Boost oder Qt?
-
+1
Schau dir mal die Berkeley-Socket-API an. Und wenn du die drauf hast, kannst du entweder dich mit boost::asio/Qt oder mit den Tiefen der Socket-Technik (z.B. Winsock 2, siehe Magazinartikel) beschäftigen.
-
Mit Winsock2 habe ich mir schonmal was kleines zusammengebastelt, und das ganze System dahinter verstehe ich auch, jetzt suche ich nur eben etwas, mit dem ich das ganze einfach, schnell und effizient umsetzen kann, denn Winsock2 war doch schon ein bisschen frickelei.
-
Wenn du sowieso schon Qt in deinem Projekt einsetzt, könnte man sich überlegen, auch dessen Netzwerkfähigkeiten zu nutzen (Einheitlichkeit usw.). Ansonsten finde ich es schon unnütz, nur wegen Netzwerk so ein riesen Framework wie Qt ins Boot zu holen, noch dazu mit nicht kompatiblen Spracherweiterungen. Davon abgesehen finde ich auch boost.asio allgemein schöner als Qt, dass ist aber eher eine subjektive Meinung.
Einen Blick wert wäre vielleicht auch Poco. Da hab ich mich noch nicht sehr damit beschäftigt, eventuell ist es aber was für dich.
-
QtBoost schrieb:
denn Winsock2 war doch schon ein bisschen frickelei.
Ehm.. na ja. Wenn die 10 Zeilen schon Gefrickel sind..
Solange man bei TCP und Berkeley-Sockets bleibt, ist das doch eigentlich alles recht angenehm.
-
Wenn die 10 Zeilen schon Gefrickel sind..
Error-Handling, plötzlicher Verbindungsabbruch, mehrfache Clients, ...
Das in 10 Zeilen mit Winsock2
-
Das kommt ein bisschen drauf an. Wenn dein Projekt an anderen Stellen schon Qt benutzt, wäre es sinnvoll, auch für die Netzwerkkomponente dabei zu bleiben - die Integration dürfte dadurch einfacher sein. Ansonsten ist Boost.Asio allerdings schöneres C++, und bei neuen Projekten würde ich vor allem deshalb von Qt absehen, weil dessen Zukunft nicht sonderlich sicher aussieht, seit Nokia (inzwischen Eigentümer von Trolltech) angekündigt hat, es nicht mehr als Entwicklungsplattform benutzen zu wollen.
-
QtBoost schrieb:
jetzt suche ich nur eben etwas, mit dem ich das ganze einfach, schnell und effizient umsetzen kann, denn Winsock2 war doch schon ein bisschen frickelei.
Du könntest dir auch den Netzwerk-Teil von SFML anschauen. Ist zumindest plattformunabhängig, recht high-level und in modernem C++ geschrieben. Ich weiss nicht, ob dir die Funktionalität ausreicht.
-
seldon schrieb:
... und bei neuen Projekten würde ich vor allem deshalb von Qt absehen, weil dessen Zukunft nicht sonderlich sicher aussieht, seit Nokia (inzwischen Eigentümer von Trolltech) angekündigt hat, es nicht mehr als Entwicklungsplattform benutzen zu wollen.
Nokia hat sicherlich dazu beigetragen Qt nach vorne zu bringen. Aber ohne den KDE-Desktop wäre Qt nicht da, wo es heute ist. Nokia hat in erster Linie die Nutzbarkeit für mobile Geräte neu eingebracht. Für die "normale" Desktopentwicklung wird Qt, wie jedes andere Opensource-Framework, weiterentwickelt werden. Jedes erfolgreiche Opensource-Projekt hat irgendwelche Firmen im Hintergrund, die das ganze finanzieren. Sollte Nokia den kommerziellen Support/Lizenz einstellen, wird das zwar für einen kurzen Moment für Unruhe sorgen, an der Qualität und Zukunft für die Desktopentwicklung wird sich deswegen nichts ändern.
Für die eigentliche Fragestellung würde ich das davon abhängig machen, was hinter der Netzwerkanbindung die Software sonst noch machen soll. Beide Libs, Boost und Qt, werden erfolgreich in Projekten eingesetzt. Für portable GUI-Programmierung ist Qt momentan, für meinen Geschmack, optimal.
-
Nokia hat sich erneut zu der Wichtigkeit von Qt bekannt.
http://www.heise.de/newsticker/meldung/Qt-als-wichtige-Komponente-von-Nokias-Next-Billion-Strategie-1264307.html
-
seldon schrieb:
...und bei neuen Projekten würde ich vor allem deshalb von Qt absehen, weil dessen Zukunft nicht sonderlich sicher aussieht, seit Nokia (inzwischen Eigentümer von Trolltech) angekündigt hat, es nicht mehr als Entwicklungsplattform benutzen zu wollen.
Da hast du eine falsche Information. Nokia wird QT zwar nicht auf Windows Smartphones nutzen, aber weiterhin QT in vielen Produkten nutzen.
Siehe hierzu auch:
-
holzeimer schrieb:
seldon schrieb:
... und bei neuen Projekten würde ich vor allem deshalb von Qt absehen, weil dessen Zukunft nicht sonderlich sicher aussieht, seit Nokia (inzwischen Eigentümer von Trolltech) angekündigt hat, es nicht mehr als Entwicklungsplattform benutzen zu wollen.
Nokia hat sicherlich dazu beigetragen Qt nach vorne zu bringen. Aber ohne den KDE-Desktop wäre Qt nicht da, wo es heute ist. Nokia hat in erster Linie die Nutzbarkeit für mobile Geräte neu eingebracht. Für die "normale" Desktopentwicklung wird Qt, wie jedes andere Opensource-Framework, weiterentwickelt werden. Jedes erfolgreiche Opensource-Projekt hat irgendwelche Firmen im Hintergrund, die das ganze finanzieren. Sollte Nokia den kommerziellen Support/Lizenz einstellen, wird das zwar für einen kurzen Moment für Unruhe sorgen, an der Qualität und Zukunft für die Desktopentwicklung wird sich deswegen nichts ändern.
Machmal ist es sehr belustigend so ein Unsinn zu lesen. Ich bezweifeln das KDE Projekt ein der Hauptentwicklungsgründe für QT ist. Höchsten ein préstige Objekt. Trolltech gehört schon ne Ewigkeit zu Nokia, trotzdem haben Sie es geschaft unabhänig zu bleiben, trotz Nokias Strategieumsturz, haben Sie weitere mobile Entwickler für Qt gesucht. Der kommerzielle Support von Qt ist schon lange an eine andere Firma übertragen wurden.
-
Zeus schrieb:
Machmal ist es sehr belustigend so ein Unsinn zu lesen. Ich bezweifeln das KDE Projekt ein der Hauptentwicklungsgründe für QT ist.
Das habe ich auch nicht behauptet. Aber die letzten 12 Jahre war das KDE-Projekt maßgeblich an der Qt-Entwicklung beteiligt. D.h. der Informationsrückfluß von KDE -> Trolltech hat den Werdegang des Frameworks stark beeinflusst. Ich bleibe bei meiner Behauptung, dass ohne KDE, die Qt-Lib nicht da wäre, wo sie heute ist.
-
holzeimer schrieb:
... Ich bleibe bei meiner Behauptung, dass ohne KDE, die Qt-Lib nicht da wäre, wo sie heute ist.
The Qt Issue schrieb:
Why did KDE choose Qt?
Qt is the best GUI toolkit available for the UNIX platform. It would have been a grave mistake to build a project of the size and scope of KDE with anything else but the best. This is particularly true for a Desktop project whose success depends critically on the availability of many great applications. It is imperative for the designers of the desktop to make application development as easy as possible.
Ja genau, man kann auch sagen Qt hat KDE geholfen. Open Source ist nun ein sehr gutes Modell gegenseitig zu beeinflussen. Wenns beiden hilft, sind alle zufrienden.
-
boost oder Qt für Netzwerkprogrammierung? Was ist denn das für eine Frage?
Qt ist einfach nur extrem hässlich.
-
theliquidwave schrieb:
Error-Handling, plötzlicher Verbindungsabbruch, mehrfache Clients, ...
Das in 10 Zeilen mit Winsock2Na gut, vielleicht ein paar mehr, aber wirklich viel Aufwand ist das nicht.
-
Hallo,
danke für eure Antworten, ich habe mich jetzt mal in Boost.Asio eingearbeitet und es geht eigentlich relativ einfach von der Hand. Also nehme ich jetzt boost
-
Qt ist einfach nur extrem hässlich.
jedes GUI Framework iss haesslich irgendwie, im vergleich zu standard c++
Qt würd ich nehmen, wenn sowieso wegens der GUI schon Qt verwendest.
Grundlagen zu Sockets sollt man eh koennen
boost zu kennen iss auch ned so verkehrt.von daher ist deine Wahl IMHO ned soo schlecht ...
Ciao ..
-
QtBoost schrieb:
Hallo,
danke für eure Antworten, ich habe mich jetzt mal in Boost.Asio eingearbeitet und es geht eigentlich relativ einfach von der Hand. Also nehme ich jetzt boostBenutzt du schön brav boost::asio::ip::tcp::iostream?
-
Öhm, bisher habe ich den nicht benutzt, habe jetzt mal kurz in die Dokumentation geguckt, aber wieso sollte man genau den nehemen?
-
QtBoost schrieb:
Öhm, bisher habe ich den nicht benutzt, habe jetzt mal kurz in die Dokumentation geguckt, aber wieso sollte man genau den nehemen?
Soll man? Nein. Kann man, muss aber nicht.
Auch mit boost::asio::ip::tcp::socket kann gut gearbeitet werden.