Netzwerkprogrammierung: Boost oder Qt?
-
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 Winsock2
Na 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.
-
Du musst ihn nicht nehmen, aber er ist noch einfacher zu verwenden als ein normaler Socket und reicht für die meisten Anwendugsfälle aus.
-
Nexus schrieb:
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.
Zum Einstieg und als erste Abstraktion zur rohen Berkeley-API ist SFML ganz nett, nutzt aber halt auch nur select und nicht IOCP/Epoll. Und High-Level ist imho was anderes