Discussion :

[cosmoff]

Bonjour,

je commence a utiliser Qt, et je trouve le framework vraiment sympa, notamment avec son systeme de signaux/slot mais aussi avec ses outils pour créer des IHM vraiment sympa.

Je dois créer pour un projet un serveur, et je me demande si je dois utiliser Qt ou le c++ standard (c++11, c++14), sachant qu'aucune IHM sera fait pour le serveur.

En gros faut il utiliser Qt uniquement quand une IHM doit etre fait, car le c++ standard offre déja tout quand on n'a pas besoin d'IHM.

Merci d'avance pour votre aide.

[koala01]

Salut,

Limiter Qt à son seul aspect IHM, c'est un peu comme vouloir limiter la notion de légumes aux carottes, parce que Qt est un framework complet qui permet -- entre autres -- de créer des IHM sympa

En l'occurrence, Qt fournit de nombreux modules, dont un qui offre des abstractions plutôt sympa pour tout ce qui a trait à la communication réseau et aux différents protocoles utilisés dans cette optique

Et ce tombe bien parce que, pour notre plus grand malheur, il n'y a encore rien qui se rapproche de la gestion des sockets dans la bibliothèque standard, version C++17 (et, sauf erreur, cela n'arrivera même pas en C++20 ... peut être en C++23 )

(hé non : le C++ moderne ne fournit pas encore "tout ce dont on peut avoir besoin )

Si bien que, si tu voulais rester sur du C++ "pur", tu devrais te tourner vers une bibliothèque externe, comme boost::asio ou similaire.

De plus, il faut se dire que les choses ont une sérieuse tendance à évoluer "en miroir" en informatique : chaque fois qu'une action est envisagée, l'action "inverse" doit aussi être envisagée en retour :

1. pour chaque fonctionnalité s'occupant d'écrire dans un fichier, il faudra sans doute une fonctionnalité permettant de lire dans le fichier
2. pour chaque fonctionnalité s'occupant d"envoyer des informations sur le réseau, il faudra sans doute une fonctionnalité permettant d'extraire les données du réseau
3. pour chaque introduction de l'utilisateur, il y aura sans doute un affichage qui sera effectué
4. j'en passe et sans doute de meilleures

Si ton objectif est de créer un "serveur" spécifique, il faut te dire que tu en viendra "rapidement" à envisager de créer un "client" qui pourra l'interroger!

Et le pire de tout, c'est

1. que le client et le serveur vont partager une partie "commune" (généralement appelée "business" ou, si tu préfères, la partie métier) et
2. que le client aura sans doute besoin d'un IHM

Généralement, on tend à insister pour que la partie métier de l'application soit le plus indépendante possible de toute bibliothèque "externe", mais, comme tu débutes en C++ et que tu auras le choix entre utiliser Qt et utiliser boost::asio (ou une autre bibliothèque externe) pour cette partie, on pourrait tout à fait comprendre que tu te tournes vers le module de Qt qui permet la gestion des sockets pour ce faire (histoire de n'avoir pas une bibliothèque "de plus" à installer et à apprendre à manipuler)

La réponse à ta question va donc malheureusement faire un peu réponse "de normand" car, ** dans l'idéal **, tu ferais sans doute effectivement bien de ne pas utiliser Qt pour la partie métier, ni pour la partie "gestion de protocole et de socket" de ton serveur (ni pour cette partie de ton application client qui suivra de près)

Mais, comme Qt fournit "tout ce qu'il faut" pour obtenir le résultat escompté, il n'y a absolument rien qui t'empêche de l'utiliser si tel est ton propre choix

[cosmoff]

merci beaucoup pour ta réponse tres complete.

Je débute dans la programmation donc d'apres ce que j'ai compris la partie client devrait etre fait avec Qt car besoin d'une IHM, et pour le serveur on doit essayer de ne pas utiliser de bibliothèque externe, mais pourquoi?
Je pourrais faire le serveur en C finalement, mais ca fait peut etre un peu sale de mélanger du C et du C++, mais en meme temps si c++ ne fourni rien pour gérer les sockets je n'ai pas trop le choix.

[koala01]

Je débute dans la programmation donc d'apres ce que j'ai compris la partie client devrait etre fait avec Qt car besoin d'une IHM, et pour le serveur on doit essayer de ne pas utiliser de bibliothèque externe,

Non, ce n'est pas ce que j'ai dit (ou, du moins, ce n'est pas ce que je voulais dire )!

J'ai dit que, si tu crées une application "serveur", il risque fort d'y avoir une deuxième application "client" qui vienne se greffer au projet, et qu'une partie de l'application "client" risque fort d'avoir besoin d'une IHM.

J'ai aussi dit que tant que les deux applications vont, de toute évidence, partager toute une partie "commune" du code, à savoir la partie qui correspond à ce que l'on appelle généralement "la partie métier" : la partie qui définit les types de données et les comportement de base des deux applications; ce que l'on peut assimiler au M de l'approche MVC (Model View Controller)

J'ai enfin dit que l' ** idéal ** était toujours de faire en sorte que cette "partie commune" aux deux applications soit aussi indépendante que possible de toute bibliothèque externe. Ce n'est cependant absolument pas une obligation !!!

mais pourquoi?

Pour une raison toute simple : sans même avoir réfléchi, nous nous retrouvons déjà pour ainsi dire avec deux applications potentielles à créer. Alors, en y réfléchissant "tout le temps nécessaire", combien d'autres applications utilisant la même "partie commune" pourrait on envisager de créer

Sauf que certaines de ces applications peuvent, à l'instar de l'application "serveur", n'avoir absolument aucun besoin d'une IHM. Ou pire encore : le(s) développeur(s) de ces autres applications pourrai(en)t tout à fait décider d'utiliser ... une autre bibliothèque d'IHM que Qt !

Or, si la "partie commune" dépend de Qt, tu rend -- pour ainsi dire -- obligatoire l'utilisation de Qt pour "le reste", parce que je te laisse imaginer le bordel que pourrait foutre dans les dépendances le fait que la partie métier (la partie commune à toutes les applications) dépendent de Qt alors que "le reste" (les parties V et C du MVC) dépendraient ... d'un autre framework

L'idée est donc que tout ce qui définit ce que l'on appelle généralement un "DSL" (Domain Specific Language, ou langage spécifique à un dommaine donné; le "jargon du métier" en quelques sortes) soit donc écrit en "pur C++", ou, au pire, en utilisant des bibliothèques capables de rester de "bas niveau", comme boost::asio.

Encore une fois : cela n'a rien d'une obligation! Après tout, il n'y a absolument rien qui dit que tu voudra créer une troisième application sur la "même base"! Et quand bien même, tu n'auras sans doute aucune raison d'abandonner Qt . Le but est donc vraiment juste de se "laisser une porte ouverte"

Je pourrais faire le serveur en C finalement, mais ca fait peut etre un peu sale de mélanger du C et du C++, mais en meme temps si c++ ne fourni rien pour gérer les sockets je n'ai pas trop le choix.

C ne fournit pas d'avantage que C++ pour gérer les sockets

Enfin, je devrais dire "pour gérer les sockets de manière portable".

Et, quand bien même, tu serais très loin d'avoir "plus facile" à le faire en C

Qt et Boost::asio fournissent de telles mécanismes portables, et ce sont deux frameworks ... utilisables en C++!

L'alternative n'est pas "dois-je utiliser C ou C++ " mais bien "dois-je utiliser Qt ou Boost::asio pour la partie commune à toutes mes applications ".

Je t'ai expliqué les raisons qui feraient que mon choix personnel serait de me tourner vers boost::asio, mais tu restes bien sur tout à fait libre de choisir l'autre solution

[cosmoff]

merci beaucoup pour ta réponse détaillée