[C++][Qt] Projet de Développement: Conseils et bonnes pratiques

Bonjour,

Je suis grand débutant en programmation C++, bien que j'ai lu de très bons tuto, et que j'ai d'anciennes bases de POO avec java et un peu de php/html.

Je suis sur un projet conséquent d'un programme assez complexe, qui sert à des automatisations de tâches et calculs. J'ai déjà effectué une bonne partie de la phase conception, en réalisant les organigrammes du futur programme. L'architecture de mon projet est composée de différents "modules", qui correspondent à des tâches bien différentes qui s'enchainent, l'enchainement étant déterminé dans un cycle séparé. En somme:

Cycle de fonctionnement: (Début)->|Module 1|->|Module 2|->|Module 3|->(Fin)
Module 1: Chaine d'actions 1
Module 2: Chaine d'actions 2
Module 3: Chaine d'actions 3

Le programme devra avoir une interface graphique, au départ pour lancer l'application, modifier les paramètres, puis lancer le cycle. Et pendant le cycle, uniquement des fenêtres de présentation de l'avancement et de l'action en cours, mais ces dernières ne doivent pas empêcher la mise en pause ou l'arrêt forcé d'un cycle. Les paramètres dont je parle seront stockés dans un fichier XML, qui servira au programme pour le fonctionnement automatique, mais qui devra pouvoir être modifié manuellement (à partir d'une interface).
L'application utilisera des matrices et des calculs relativement poussés, une communication par port COM ainsi que des envois de résultats sur un serveur (ftp ou autre...).

1- Ai-je été suffisamment clair dans la présentation de mon projet?

Après différentes recherches, je pense m'orienter vers:
- une programmation en C++
- l'utilisation de Qt, notamment pour l'interface graphique, la lecture/écriture XML, et le fonctionnement réseau (COM et serveur)
- l'utilisation de la bibliothèque BOOST pour tout ce qui touche aux matrices

2- Ces choix sont-ils a priori pertinents?

3- Les bases sont à présent posées. Pour le développement à proprement parler, quelle est la marche à suivre? C'est-à-dire, d'une part, comment organiser le code, et d'autre part, utiliser les bibliothèques.
Dois-je programmer mes "modules" en C++, séparément, et ne prévoir Qt que pour afficher le tout par la suite, ou dois-je programmer mes modules directement dans Qt (en utilisant les variables de Qt les types, etc...)?

4- L'architecture de mes fichiers de code sera-t-elle la suivante:
- main.cpp: lancement du programme, interface graphique
- cycle.cpp: cycle principal appelé par le main, et appelant les modules
- module1.cpp: module 1, enchainement de tâches
- module2.cpp: module 2, enchainement de tâches
- module3.cpp: module 3, enchainement de tâches
- classeQt1.cpp: interface correspondant au module 1
- classeQt2.cpp: interface correspondant au module 2
- classeQt3.cpp: interface correspondant au module 3
- classePerso1.cpp: une classe d'objets utilisés dans le programme
- classePerso2.cpp: une autre classe d'objets utilisés dans le programme

J'espère avoir été assez clair dans mes interrogations,

Merci pour vos réponses.

Salut, et bienvenue sur le forum

Citation:

---

1- Ai-je été suffisamment clair dans la présentation de mon projet?

---

Tu es certes resté relativement imprécis dans ce qui sera fait dans les différents modules, mais, oui, de manière générale, la présentatin que tu fais permet de se faire une idée assez précise du résultat que tu souhaites obtenir...

Il y aura cependant certaines questions d'ordre beaucoup plus précise qui viendront pour arriver à te proposer le meilleur choix ;)

Citation:

---

Après différentes recherches, je pense m'orienter vers:
- une programmation en C++
- l'utilisation de Qt, notamment pour l'interface graphique, la lecture/écriture XML, et le fonctionnement réseau (COM et serveur)
- l'utilisation de la bibliothèque BOOST pour tout ce qui touche aux matrices

2- Ces choix sont-ils a priori pertinents?

---

Cela semble, en effet, cohérent, même si, à titre tout à fait perso, je préférerais éviter le recours au système COM...:

Qt, tout comme boost, fournissent des ensemble de classes spécialisées dans la gestion du réseau, par exemple, et COM est tout, sauf parfaitement portable (et donc, à n'utiliser qu'en cas d'obligation forcée, selon moi ) ;)

Citation:

---

3- Les bases sont à présent posées. Pour le développement à proprement parler, quelle est la marche à suivre? C'est-à-dire, d'une part, comment organiser le code, et d'autre part, utiliser les bibliothèques.

---

L'idéal est d'avancer "pas par pas", "module par module"...

Essaye de faire en sorte qu'un module fonctionne correctement avant de t'attaquer au module suivant ;)

Cela implique de savoir déterminer quel module dépend des autres, meme si, dans un premier temps, tu peux parfaitement te contenter d'une gestion se contentant d'afficher "ici, tel module prend le relais" ;)

N'oublie surtout pas les de mettre en place une politique stricte de tests unitaires, non seulement pour t'assurer que ce que tu fais correspond bien à ce que tu attends, mais aussi pour avoir la certitude que, les évolutions aidant (il arrivera fatalement un moment où tu devras revenir sur "de l'existant" pour l'adapter aux besoins d'une nouvelle fonctionnalité ;)), tu n'apporte pas une modification qui a pour résultat de "tout casser" ;)

Citation:

---

Dois-je programmer mes "modules" en C++, séparément, et ne prévoir Qt que pour afficher le tout par la suite, ou dois-je programmer mes modules directement dans Qt (en utilisant les variables de Qt les types, etc...)?

---

A titre purement personnel, je dirais que l'idéal est d'essayer de se limiter à ce que fournit le C++ en standard et à boost pour toute la partie "business" de ton projet, et d'essayer de limiter l'utilisation de Qt à la partie purement relative à l'IHM, voire à la partie "controler" de ton application.

Cela permettra plus facilement de garder la partie métier et de ne refaire que la partie propre à l'IHM en cas de besoin ;)

Maintenant, ce conseil est strictement personnel, parce que j'aime l'idée de découpler le plus possible la partie métier de la partie purement graphique, mais d'autres pourraient avoir des avis différents (et pas forcément sans fondement ;))

Citation:

---

4- L'architecture de mes fichiers de code sera-t-elle la suivante:
- main.cpp: lancement du programme, interface graphique
- cycle.cpp: cycle principal appelé par le main, et appelant les modules
- module1.cpp: module 1, enchainement de tâches
- module2.cpp: module 2, enchainement de tâches
- module3.cpp: module 3, enchainement de tâches
- classeQt1.cpp: interface correspondant au module 1
- classeQt2.cpp: interface correspondant au module 2
- classeQt3.cpp: interface correspondant au module 3
- classePerso1.cpp: une classe d'objets utilisés dans le programme
- classePerso2.cpp: une autre classe d'objets utilisés dans le programme

---

C'est très certainement une base de travaille cohérente, mais il y a de fortes chances que l'idéal soit quand meme de séparer les fonctionnalités de chaque module en autant de fichier (en-tête + implémentation !!! ) qu'il y aura de classes dans le module ;)

Tu pourrais donc très facilement te retrouver avec quelque chose comme

1. [*]module 1 (c++ "pur" + boost éventuel)
   
   • classe1.h + classe1.cpp
   • classe2.h + classe2.cpp
   • classe3.h + classe3.cpp
2. module 2 (c++ "pur" + boost éventuel)
   
   • classe4.h + classe4.cpp
   • classe5.h + classe5.cpp
   • classe6.h + classe6.cpp
3. module 3 (c++ "pur" + boost éventuel)
   
   • classe7.h + classe7.cpp
   • classe8.h + classe8.cpp
   • classe9.h + classe9.cpp
4. module "controleur" (Qt + moduel1 + module2 + module3 + C++ "pur" + boost éventuel )
   
   • controleur1.h + controleur1.cpp
   • controleur2.h + controleur2.cpp
   • controleur3.h + controleur3.cpp
   • controleur4.h + controleur4.cpp
   • controleur5.h + controleur5.cpp
5. module "ihm" (Qt +controleur)
   
   • widget1.h + widget1.cpp
   • widget2.h + widget2.cpp
   • widget3.h + widget3.cpp
   • widget4.h + widget4.cpp
   • widget5.h + widget5.cpp
   • widget6.h + widget6.cpp
   • widget7.h + widget7.cpp
   • widget8.h + widget8.cpp
   • widget9.h + widget9.cpp

Le tout en prévoyant, pourquoi pas, des dossier différents pour les différents modules ;)

Tout d'abord, merci beaucoup koala01 pour cette réponse à la fois rapide et très complète!

1- Je suis effectivement resté évasif pour la description de manière à ne pas rentrer dans des détails alourdissant la description. Je trouvais qu'elle était déjà suffisamment longue pour ne pas en rajouter ^^
Si besoin, je peux bien entendu développer plus le concept, si cela peut aider à apporter plus de réponses et/ou suggestions.

2- L'utilisation d'un port COM sera effectivement obligatoire dans mon application, donc cela ne peut pas être écarté. D'où mon intérêt pour Qt qui, en plus du GUI et du XML, permet de gérer cela.

3- Dans le fonctionnement prévu, chaque module a besoin du précédent et est nécessaire au suivant (n dépend de n-1 et permet n+1). Par conséquent, ce que tu me proposes confirme mes premières idées, de faire les modules séparément, de les tester indépendamment, et de fusionner le tout une fois que chacun fonctionne.

4- A priori, l'architecture que j'aurai à utiliser se situe entre ma proposition et la tienne. J'avoue qu'en tant que débutant elle me parait encore un peu (ou beaucoup) floue, car bien plus complexe que tous les tutoriels que j'ai pu parcourir.
Ce que j'ai encore du mal à concevoir, c'est l'enchainement des actions des modules. Dans ma conception du programme, j'ai envisagé que le module de départ charge le fichier XML, crée les objets nécessaires, et passe la main à la suite. Dans cette suite, chaque module ne crée aucun objet, mais utilise les objets initiaux (ou des variables intermédiaires), avant de les passer au suivant. Pour chaque étape, on aurait une interface simple représentant l'avancement.

Suivant cela, on n'a besoin que d'une seule classe d'objets, et à coté de celle-ci, les modules ne feront que des actions sur ces objets.

Je fais peut-être une confusion entre classe et fichier .cpp et .h?
Jusqu'à présent, pour chaque nouvelle classe, je faisais un fichier .cpp et un .h. Là, je devrais créer des fichiers .cpp et .h sans créer de classe, pour chaque module? Ou est-ce que ce que j'appelle "module" sera représenté dans le programme par une classe?
A ce moment là, les actions réalisées seront les méthodes de la classe?

5- Je m'égare peut être un peu dans mes questions, mais toutes sont liées au programme, et à la programmation qui sera choisie.
Qt est sous licence LGPL, par conséquent, mon programme pourrait potentiellement être propriétaire, il suffirait que je fournisse à coté du .exe de mon application les .dll de Qt utilisées et les parties de mon programme qui utilisent Qt, est-ce bien cela?

Si c'est effectivement les conditions, le fait de séparer le "C++ pur" et Qt permettraient de ne divulguer que mes classes qui héritent de Qt, à savoir l'interface graphique, la lecture XML, et les parties serveur, tout en gardant toutes les parties "calcul" confidentielles. Me trompe-je?

6- Tu sépares un module "contrôleur" d'un module "ihm". l'IHM correspond à tout ce qui est affichage? C'est-à-dire fenêtres de progression, d'accueil et de paramétrage. Mais à quoi correspond le contrôleur? Ce sont toutes les fonctions appelées par les boutons de l'interface?

Encore une fois un post un peu long... merci de l'avoir lu jusqu'ici ;)

Citation:

---

Envoyé par Gm7468

3- Dans le fonctionnement prévu, chaque module a besoin du précédent et est nécessaire au suivant (n dépend de n-1 et permet n+1). Par conséquent, ce que tu me proposes confirme mes premières idées, de faire les modules séparément, de les tester indépendamment, et de fusionner le tout une fois que chacun fonctionne.

---

Ce que tu appelles "module" fait quand meme furieusement penser à des fonctionnalités ou à des étapes à respecter ;)

Mais rien n'empêche, effectivement, de créer des modules séparés ;)

Citation:

---

4- A priori, l'architecture que j'aurai à utiliser se situe entre ma proposition et la tienne. J'avoue qu'en tant que débutant elle me parait encore un peu (ou beaucoup) floue, car bien plus complexe que tous les tutoriels que j'ai pu parcourir.

---

Ce qui importe avant tout, c'est de déterminer les bonnes responsabilités pour chaque étape, et de regrouper les fonctionnalités utiles à chaque responsabilité dans le "bon nombre" de classe (ayant chaque fois une responsabilité unique ;))

A partir de là, il y a généralement deux fichiers à prévoir : un fichier d'en-tête (*.h / *.hpp ) qui fournit qui définit la classe et déclare ses membres et fonctions associées, et un fichier d'implémentation (*.cpp) qui fournit l'implémentation des fonctions membres et associées

Citation:

---

Ce que j'ai encore du mal à concevoir, c'est l'enchainement des actions des modules. Dans ma conception du programme, j'ai envisagé que le module de départ charge le fichier XML, crée les objets nécessaires, et passe la main à la suite. Dans cette suite, chaque module ne crée aucun objet, mais utilise les objets initiaux (ou des variables intermédiaires), avant de les passer au suivant. Pour chaque étape, on aurait une interface simple représentant l'avancement.

---

C'est effectivement cohérent, mais il faut rester conscient que, pour effectuer une partie du traitement, il n'est pas impossible que tu doive recourir à plusieurs classes afin de respecter cette fameuse règle de "responsabilité unique" ;)

Citation:

---

Suivant cela, on n'a besoin que d'une seule classe d'objets, et à coté de celle-ci, les modules ne feront que des actions sur ces objets.

---

Tu auras sans doute une seule classe "donnée", mais tu peux avoir plusieurs classes qui la manipulent, et qui prendront chacune une partie du traitement en charge ;)

Citation:

---

Je fais peut-être une confusion entre classe et fichier .cpp et .h?

---

En fait, le couple fichier *.h + fichier *.cpp est ce qui permet de fournir en C++ l'implémentation du concept représenté par la classe...

Je m'explique : Une classe fournit le concept d'un objet plus ou moins concret que l'on utilise (par exemple :la classe Voiture fournit le concept informatique de l'objet correspondant dans la "vie de tous les jours")

Le couple de fichier *.h + *.cpp est la "traduction" de ce concept dans le langage (ici C++) qui permettra, après traitement (la compilation, dans le cas du C++, ou l'interprétation pour d'autre langages ;)), à l'ordinateur de manipuler ce concept ;)

Citation:

---

Jusqu'à présent, pour chaque nouvelle classe, je faisais un fichier .cpp et un .h.

---

C'est effectivement ce qu'il faut faire ;)

Citation:

---

Là, je devrais créer des fichiers .cpp et .h sans créer de classe, pour chaque module?

---

Tu ne dois pas créer de fichier pour le plaisir d'en créer, surtout si c'est pour les laisser vide ;)

Ce qui se passe, c'est que le système de fichier est le meilleur moyen pour organiser ton travail : tu mets dans un fichier tout ce qui "va bien ensemble" : une classe, d'éventuelles constantes et d'éventuelles fonctions libres qui utilisent / seront utilisées par la classe.

De cette manière, tu disposes (au travers du fichier d'en-tête) de "tout ce qu'il faut" pour utiliser la classe.

ainsi, on peut estimer que la valeur de PI, les fonctions sinus, cosinus, tangeante et cotangeante sont autant de choses qui "vont bien ensemble" et que l'on peut donc trouver dans un fichier unique : math.h

Un module est à considéré comme un "ensemble de fonctionnalités" nécessaire à l'obtention d'un résultat complexe.

Ainsi, tu pourrais très bien avoir un autre fichier regroupant la structure "date_time" et les fonctions qui permettent de manipuler des dates et des heures (parce que ca "va bien ensemble"), et mettre dans un meme module les fonctionnalités de gestion de date et d'heure d'une part et les fonctionnalités de mathématique parce que tu as besoin de ces deux ensembles de fonctionnalités pour obtenir le résultat qui t'intéresse ;)

Citation:

---

A Ou est-ce que ce que j'appelle "module" sera représenté dans le programme par une classe?

---

Un module a, souvent, de fortes chances d'être meme représenté par un ensemble de classes ;) :

Bien souvent, tu as une ou plusieurs classe "de données" manipulées et une ou plusieurs classes qui les manipule(nt) (des classes "métier" ;)).

Tu as en effet souvent plusieurs ensembles de fonctionnalités "qui vont bien ensemble" qui permettent, en travaillant "de concert", d'obtenir un résultat donné ;)

Citation:

---

A ce moment là, les actions réalisées seront les méthodes de la classe?

---

En conception orientée objet, on considère généralement que les différentes actions sont des méthodes de la classe qui a la responsabilité correspondante ;)

Maintenant, comme j'ai essayé de te l'expliquer depuis le début, chaque classe doit (devrait, idéalement) n'avoir qu'une responsabilité limitée, "concrétisée" éventuellement par plusieurs fonctions membres, et il faut donc veiller à ce que la "bonne fonction" soit membre de "la bonne classe" ;)

Citation:

---

5- Je m'égare peut être un peu dans mes questions, mais toutes sont liées au programme, et à la programmation qui sera choisie.
Qt est sous licence LGPL, par conséquent, mon programme pourrait potentiellement être propriétaire, il suffirait que je fournisse à coté du .exe de mon application les .dll de Qt utilisées et les parties de mon programme qui utilisent Qt, est-ce bien cela?

Si c'est effectivement les conditions, le fait de séparer le "C++ pur" et Qt permettraient de ne divulguer que mes classes qui héritent de Qt, à savoir l'interface graphique, la lecture XML, et les parties serveur, tout en gardant toutes les parties "calcul" confidentielles. Me trompe-je?

---

Cela va meme plus loin :

La seule chose dont tu dois fournir le code source (ou le moyen de l'obtenir) des classes faisant partie de Qt (ou des éventuelles modifications que tu y apporterait).

Les classes que tu crées qui dépendent de Qt peuvent parfaitement être propriétaires, tout comme le programme en lui-même ;)

Citation:

---

6- Tu sépares un module "contrôleur" d'un module "ihm". l'IHM correspond à tout ce qui est affichage? C'est-à-dire fenêtres de progression, d'accueil et de paramétrage.

---

C'est bien cela ;)

Citation:

---

Mais à quoi correspond le contrôleur? Ce sont toutes les fonctions appelées par les boutons de l'interface?

---

C'est la partie qui va controler toutes les communications entre la partie métier et l'IHM:

Si une erreur survient (au niveau métier) lors de l'exécution, c'est le controleur qui dira à l'IHM comment réagir

Si l'utilisateur introduit un chiffre au lieu d'un texte, par exemple, c'est le controleur qui signalera directement à l'utilisateur (au travers de l'IHM) "qu'il s'est gouru"

C'est encore le controleur qui permettra de mettre certaines données "métier" en forme au niveau de l'IHM ;)

Bref, le controleur, c'est vraiment ce qui fait le lien (dans les deux sens !!! ) entre la partie métier et la partie graphique ;)

Encore une fois, merci koala01, des réponses toujours aussi pertinentes et complètes ;)

Citation:

---

Envoyé par koala01

Ce que tu appelles "module" fait quand meme furieusement penser à des fonctionnalités ou à des étapes à respecter ;)

---

C'est complètement cela oui. Mais comme ils sont relativement conséquents, souvent même je les ai séparés en sous-modules, je les ai "pensés" indépendamment.

Citation:

---

Envoyé par koala01

La seule chose dont tu dois fournir le code source (ou le moyen de l'obtenir) des classes faisant partie de Qt (ou des éventuelles modifications que tu y apporterait).
Les classes que tu crées qui dépendent de Qt peuvent parfaitement être propriétaires, tout comme le programme en lui-même ;)

---

Là je ne suis pas sur de suivre totalement... Que je doive fournir les dll de Qt, d'accord, les modifications, ok également (de toute façon je ne ferai pas de modifications à proprement parler). Cependant, les classes que je crée qui dépendent de Qt, de par l'héritage (par exemple l'IHM dont les fenêtres héritent de classes Qt), sont des "travaux qui dérivent de la bibliothèque" comme le présente la licence, et donc elles doivent être fournies au même titre que Qt non?


J'ai l'impression que nous sommes en phase pour tout le reste, ou du moins que tu as éclairé pour le moment tout ce dont j'avais besoin.

Encore un grand merci pour tes réponses!
Je reviendrai peut-être si d'autres interrogations me viennent en cours de développement ^^

Une nouvelle question me vient à l'esprit, je sèche un peu dans le code.
J'ai donc pour le moment cette architecture:
- main.cpp
- objet1.cpp
- objet1.h
- objet2.cpp
- objet2.h

Jusque là, tout va bien. Dans mon main.cpp, j'ai une fonction main qui fait différentes petites choses, et d'autres fonctions à coté pour des calculs (qui utilisent ou non les objets).
Je voudrais mettre ces fonctions annexes ailleurs, et que je puisse les appeler depuis le main, ou depuis n'importe quel module où j'en aurait besoin.

J'ai ainsi créé deux nouveaux fichiers: fonctions.cpp et fonctions.h, pour définir la classe fonctions qui contient les fonctions qui étaient précédemment dans le main. Seulement, lors des appels, le compilateur m'envoie une erreur, car aucun objet fonctions n'est créé. C'est logique.
J'ai pensé à faire une classe abstraite, mais alors faudrait-il que mes classes objetx héritent de fonctions pour pouvoir utiliser les fonctions...?

Comment organiser mon code (fichiers, création de classes ou non) pour que je puisse utiliser les différentes fonctions facilement sur les différents objets?

Ce n'est pas une classe abstraite qu'il faut faire, mais soit faire des fonctions libres (après tout, c'est tout à fait autorisé en C++ :D ) soit, faire des fonctions membres statiques.

Les fonction dites "statiques" ont, en effet, l'énorme avantage d'être indépendantes de toute instance de la classes dans laquelle elles sont déclarées mais peuvent, si tu leur transmet une instance particulière de la classe en question, accéder librement à n'importe quel (quelle fonction) membre de la classe, exactement comme n'importe quelle autre fonction membre de la classe ;)

Tu pourrais donc tout à fait avoir quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Functions // un nom plus précis serait utile pour éviter de te retrouver // une classe "fourre tout" tant il y aura de fonctions :D { public: static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* toutes les fonctions statiques */ } /* OU OU OU OU */ /* namespace MyNamespace { */   static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* toutes les fonctions libres */ /* } */

---

Et tu pôurrais meme envisager de les séparer dans plusieurs classes / (sous-)espaces de noms / fichiers en fonction du domaine auquel elles se rapportent ;)

Les fonctions membres statiques sont utilisées sous une forme proche de

Code:

---

1 2 3 4 5 6

int main() { Functions::doSomething(/* arguments */ ); UnType result = Functions::doOtherThing(/* arguments */ ); /*...*/ }

---

L'utilisation des espaces de noms permet d'éviter les éventuelles ambiguités, et, surtout, de regrouper l'ensemble des classes / fonctions qui "vont bien ensemble" (on pourrait presque faire le parallèle entre ce qu'on trouve dans un espace de noms et ce que l'on trouve dans un module ;) )

On peut y accéder en qualifiant pleinement le nom de la fonction

Code:

---

1 2 3

MyNamespace::doSomething(/* arguments */ ); UnType result = MyNamespace::doOtherThing(/* arguments */ );

---

ou en utilisant la directive using namespace. On peut alors accéder aux fonctions sans les qualifier, exactement comme si elles étaient hors de tout espace de noms

Code:

---

1 2 3 4 5 6 7 8

using namespace MyNamespace;   void foo() {   doSomething(/* arguments */ ); UnType result = doOtherThing(/* arguments */ ); }

---

Cependant, la directive using namespace ne devrais jamais se retrouver dans un fichier d'en-tête et certains vont même jusqu'à conseiller de ne l'utiliser que dans le scope d'une fonction, parce qu'elle reste active jusqu'à la fin de la portée dans laquelle elle se trouve ou , si elle se trouve hors de toute portée, entre l'endroit où elle se trouve et la fin du fichier.

La placer dans un fichier d'en-tête revient donc à perdre entièrement le controle de l'activité de cette directive à cause des inclusions en cascades (elle serait en effet active dans un fichier XXX.cpp qui inclut un fichier qui inclut un fichier qui inclut un fichier ...(je pourrais continuer longtemps comme cela ;) ) qui inclut le fichier d'en-tete dans lequel elle est ;)

Je n'ai pas tout lu, peut etre mon message est inutile, mais pour la decomposition en modules, etats, etc. il y a le game state pattern qui peut t'etre utile.

Merci pour vos réponses!
koala01, c'est exactement ce que je recherchais, merci!

Citation:

---

Envoyé par Gm7468

Là je ne suis pas sur de suivre totalement... Que je doive fournir les dll de Qt, d'accord, les modifications, ok également (de toute façon je ne ferai pas de modifications à proprement parler). Cependant, les classes que je crée qui dépendent de Qt, de par l'héritage (par exemple l'IHM dont les fenêtres héritent de classes Qt), sont des "travaux qui dérivent de la bibliothèque" comme le présente la licence, et donc elles doivent être fournies au même titre que Qt non?

---

Il faudrait que je relise le contrat de licence, mais, pour autant que je me souvienne, Qt est fourni en licence LGPL.

Si la licence GPL est très virale (tout ce qui utilise quelque chose sous licence GPL doit respecter lui meme la licence GPL et etre fournis selon les règle de la licence GPL), il me semble que la licence LGPL s'arrête au composants fournit sous cette licence.

Ainsi, il est clair que tu ne peux pas prendre les sources de Qt, les compiler et fournir Qt sous une licence propriétaire (ou non GPL).

Il est aussi clair que, si tu rajoute dans Qt une classe de la mort qui tue, tu devras fournir cette classe sous licence LGPL et au moins la proposer à l'équipe de dev de Qt (qui restera libre de l'introduire ou non), et que, tant que tu utiliseras cette classe, tu devras t'assurer que son code source est disponible.

Par contre, il me semble que tu restes totalement libre de choisir la licence que tu veux pour ce qui "ne fait qu'utiliser" une bibliothèque sous licence LGPL, à condition que la bibliothèque sous licence LGPL soit utilisés sous forme de shared lirary (dll sous windows, so sous linux) mais, comme je l'ai dit, il vaut mieux relire le texte et attendre confirmation ;)

Citation:

---

Envoyé par koala01

Il est aussi clair que, si tu rajoute dans Qt une classe de la mort qui tue, tu devras fournir cette classe sous licence LGPL et au moins la proposer à l'équipe de dev de Qt

---

Cela va sans dire que je partagerai ma création de super classe ;)
Cependant, dans un premier temps, je vais me contenter de comprendre correctement les ficelles du C++ et de Qt, et de faire fonctionner le tout pour les besoins qui sont les miens, nous verrons par la suite le développement de la mort qui tue 8-)

Je pense que tu te souviens assez bien de la licence LGPL. Mon seul problème est au niveau de l'héritage, mais en lisant le texte officiel je n'arrive pas à comprendre correctement cette partie. A priori le texte est flou sur l'héritage...

Citation:

---

Envoyé par koala01

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Functions // un nom plus précis serait utile pour éviter de te retrouver // une classe "fourre tout" tant il y aura de fonctions :D { public: static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* toutes les fonctions statiques */ } /* OU OU OU OU */ /* namespace MyNamespace { */   static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* toutes les fonctions libres */ /* } */

---

---

Cela m'intéresse tout particulièrement! :P
Pour être sur de bien comprendre:
J'ai le choix entre les deux manières de faire c'est bien cela?
Soit faire une classe:

Code:

---

1 2 3 4 5 6

class Module 1 { public: static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* fonctions statiques */ }

---

Soit faire un namespace:

Code:

---

1 2 3 4 5

namespace Module 1 { static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* fonctions libres */ }

---

Ou bien est-ce que je me trompe et je suis forcément obligé de faire d'abord une classe, avec la possibilité d'y insérer un namespace?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Module 1{ public: static void doSomething(/* parametres éventuels */); static UnType /* const */ /* &*/ doOtherThing(/* paramètres éventuels */); /* fonctions statiques */ } namespace Namespace de Module 1{ static void doOtherThing(/* parametres éventuels */); static UnType /* const */ /* &*/ doAnotherThing(/* paramètres éventuels */); /* fonctions libres */ }

---

Dans ce dernier cas, la classe serait la déclaration des fonctions et le namespace leur implémentation ou les deux contiendraient des fonctions totalement différentes?

Ce qu'il y a de bien, avec C++, c'est que tu restes tout à fait libre de faire ce que tu veux :D

L'approche "tout objet" (celle de java ou de C#, par exemple) "t'imposerait" de créer une classe avec des fonctions membres (éventuellement statique), mais l'approche C++ est de te laisser le choix entre soit créer une classe avec des fonctions membre, soit créer des fonctions libres (comprend : n'appartenant à aucune classe), éventuellement dans un espace de noms, soit, enfin, de placer certaines fonctions dans une (ou plusieurs ) classes et d'en placer d'autres dans un espace de noms :D

Le tout est quand meme d'essayer d'assurer un minimum de cohérence à ton projet, et, de ce point de vue là, il est peut etre plus difficile de justifier que, pour certaines fonctions, tu aies pu choisir de créer une classe qui ne contiendrait que des fonctions membres statiques, et que pour d'autre, tu aurais à l'inverse décidé de créer un espace de noms :aie: ;)

D'accord.
Et si je choisis par exemple de prendre le fonctionnement des namespaces. J'aurais donc par exemple d'un coté les classes d'objets manipulés, et d'un autre, les namespaces. Les premières seraient définies comme habituellement dans des fichiers .h pour les déclarations et .cpp pour les implémentations. Mais comment procéder pour les secondes?
J'ai un peu testé et je n'arrive à faire fonctionner le système de namespace qu'en utilisant un fichier .h, et en plaçant tout dedans (le namespace et l'implémentation immédiate des fonctions). Ainsi, j'ai le main, une classe d'objets, et un fichier .h avec le namespace et les fonctions statiques dedans, le tout a l'air fonctionner.
Est-ce la marche à suivre?

Le principe pour les espaces de noms est strictement le meme que le principe pour les classes...

Il faut "juste" veiller à :

• déclarer et définir la fonction dans le meme espace de noms
• utiliser le nom pleinement qualifié (ex [codeinline]<espace de noms>::foo(/* arguments */);[codeinline]de la fonction si tu l'utilise en dehors de l'espace de noms dans lequel elle est déclarée

Quelques exemples valant mieuw qu'un long discours :
Partons d'un premier fichier d'en-tête (utils.hpp)proche de

Code:

---

1 2 3 4 5 6 7 8

#ifndef UTILS_HPP #define UTILS_HPP namespace Utils { void foo(); void bar(); } //namepsace Utils #endif UTILS_HPP

---

il les fonctions foo et bar seront implémentées dans utils.cpp sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <Utils.hpp> namespace Utils { void foo() { //ce qui doit etre fait } void bar() { //ce qui doit etre fait }   } //namespace Utils

---

On peut avoir un espace de noms imbriqué (qui se trouve lui meme dans un espace de nom), ce qui serait, par exemple, le cas de fonctions relative au logging, et que l'on pourrait considérer comme étant... utilitaires.
Elle seraient déclarée dans un fichier logging.hpp sous la forme de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#ifndef LOGGIGN_HPP #define LOGGIGN_HPP namespace Utils { namepsace Logging { void truc1(/* ...*/); void truc2(/*...*/); } // namespace Logging } // namespace Utils #endif // LOGGIGN_HPP

---

Comme l'espace de noms Logging est imbriqué dans l'espace de noms Utils, tout ce qui se trouve dans Logging peut voir (pour autant que le fichier d'en-tete correspondant soit inclus ;) ) ce qui se trouve dans l'espace de noms Utils.

truc1 et truc2 pourraient donc tout à fait utiliser foo et bar sous une forme proche de (fichier Logging.cpp)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <Utils.hpp> #include <Logging.hpp> namespace Utils { namespace Logging { void truc1(/*...*/) { foo(); } void truc2(/*...*/) { bar(); }   } // namespace Logging } // namespace Utils

---

tu pourrais avoir, par ailleurs, un espace de noms Business qui regrouperait tout ce qui a trait à la partie métier.

La partie métier peut, parfaitement utiliser les éléments de Utils, sous une forme proche de (business.hpp)

Code:

---

1 2 3 4 5 6 7 8 9

#ifndef BUSINESS_HPP #define BUSINESS_HPP namespace Busines { void doSoemthing(/* ... */); void doOtherthing(/*...*/);   } // namespace Business #endif // BUSINESS_HPP

---

dont les fonctions seraient définies sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include "Business.hpp" #include "Utils.hpp" #include "Logging.hpp" namespace Business { void doSomething(/*...*/) { Utils::foo(); Utils::bar(); } void doOtherthing(/*... */) { Utils::Logging::truc1(); Utils::Logging::truc2(); }   } // namespace Business

---

Et tu pourrais enfin avoir la fonction main, qui se trouve dans l'espace de noms global, qui ressemblerait à

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include "Business.hpp" #include "Logging.hpp" #include "Utils.hpp"   int main() { /* on peut placer la directive using namespace dans un scope ;) */ using namespace Utils; using namespace Utils::Logging; using namespace Busines; foo(); bar(); truc1(); truc2(); doSomething(); doOtherthing();; return 0; }

---

Bien sur, les espaces de noms peuvent contenir des structures et ou des classes, si besoin en est ;)

Ok merci pour toutes ces réponses.
Je vais tester ca alors.
Est-ce que le problème peut venir du fait que j'utilise un fichier .h et pas .hpp?

Non...

j'utilise personnellement l'extension *.hpp pour faire la distinction entre les en-tête de C (pour lesquelles j'utilise *.h), mais ce n'est qu'une convention personnelle ;)

Il n'y a, en effet, aucune restriction en terme d'extension pour les fichiers d'en-tête (regarde la SL : elle utilise des noms de fichiers sans extension ;) ), et tu pourrais meme décider d'utiliser l'extension *.flutecacaboudin si tu le voulais ;)

Le tout fonctionne à présent correctement!
Pour info, mon problème venait du fait que j'avais laissé le mot clé "static" lorsque je définissais les fonctions de mon namespace.

Encore merci pour toutes ces réponses!

Me revoilà pour une nouvelle question.

L'architecture des fichiers et modules est à présent réglée.

Je me heurte cependant à un nouveau problème, assez basique, mais non moins primordial: les variables et leur portée.
Pour les portées "minimales", avec les variables utilisées uniquement dans des fonctions, aucun problème.
Par contre, comment faire (déclaration, structure du code, etc...) pour manipuler des "variables globales"?

Ces dernières sont, d'une part, les objets utilisés, et d'autre part, des variables simples qui ont à être passées de module en module.
J'aimerais donc créer ces variables au début, pour pouvoir les appeler/modifier par la suite, à partir de différents fichiers, différentes fonctions, etc...

Dois-je faire un namespace spécial "Globales" et toutes les déclarer dedans, et je pourrais les initialiser, modifier ailleurs?
Dois-je les déclarer dans le main au tout début du programme (peu propre à mon avis...)?
...?

Personnellement, je suis plutôt d'avis de limiter autant que possible (pour ne pas dire "de proscrire" :D )l'utilisation des variables globales et autres "anti patterns" comme le singleton ou le "monostate"...

La raison de cette réaction est bien simple : dés qu'une variable devient globale, on perd littéralement tout contrôle sur les actions qui peuvent être effectuées dessus :aie:

A choisir, je préférerais encore avoir une structure regroupant toutes ces variables et constante, créée et initialisée dans a fonction principale (ou dans le premier module, en fonction des besoins et des circonstances ;) ) et transmise, de préférence sous la forme d'une référence non constante, "de module en module".

La fonction principale pourrait alors ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

int main() { StructureDonneePartagee datas( /* paramètres éventuels */); { Module1 m1(datas); m1.execute(); }   { Module2 m2(datas); m2.execute(); }   { Module3 m3(datas); m3.execute(); }   { Module4 m4(datas); m4.execute(); } /* ...*/ }

---

J'ai présenté l'exemple dans la fonction main, mais cela pourrait parfaitement se trouver dans une fonction de l'interface graphique (pour qu'elle puisse "récupérer la main entre le lancement de deux modules ;) )

J'avais vu que les variables globales étaient déconseillées, mais mon statut de débutant me faisait encore défaut et cette notion de structure - effectivement très intéressante dans mon cas - me manquait.

J'ai parcouru certains cours sur les structures, si je comprends bien, c'est en quelque sorte une notion de classe diminuée?
Puisque la structure a des champs, qui correspondent plus ou moins à des attributs de classe. Les classes ont juste les méthodes en plus.
Jusque là est-ce exacte?
Si oui, pourquoi favoriser une structure, plutôt qu'une classe d'objet?
Est-ce pour l'avantage de la simplicité? (uniquement des champs/attributs et pas les méthodes, et les "problèmes de l'encapsulation?)

Peut-on placer ce qu'on veut dans une structure?
A savoir, des variables "habituelles", mais aussi par exemple des tableaux, listes, ou maps dynamiques d'objets persos?

En utilisant ce fonctionnement, je devrais donc déclarer la structure au début, par exemple dans le premier module. Pourrais-je créer une fonction initialise(datas), qui initialiserait les champs de cette structure, séparément de la déclaration? Ou faut-il forcément initialiser les champs dès la déclaration?

Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct MaStructure { int variable1; double variable2; objetx variable3; map<int, objety> variable4; };   struct datas;   initialise(datas) { variable1 = 2; variable2 = 3.1415926535; ... }

---

Citation:

---

Envoyé par Gm7468

J'avais vu que les variables globales étaient déconseillées, mais mon statut de débutant me faisait encore défaut et cette notion de structure - effectivement très intéressante dans mon cas - me manquait.

J'ai parcouru certains cours sur les structures, si je comprends bien, c'est en quelque sorte une notion de classe diminuée?
Puisque la structure a des champs, qui correspondent plus ou moins à des attributs de classe. Les classes ont juste les méthodes en plus.
Jusque là est-ce exacte?

---

En fait, en C++ du moins, la différence entre une classe et une structure est meme encore plus subtile:

La seule différence qu'il y ait en C++ tient dans la visibilité par défaut des membres et des fonctions membres ;)

Par défaut (comprend : tant que tu n'as pas indiqué une visibilité (private: protected: ou public: ), les classes ont une visibilité privée et les structures ont une visibilité publique (y compris en ce qui concerne l'héritage ;))

A cette différence près, les classes et les structures s'utilisent exactement de la même manière ;)

Citation:

---

Si oui, pourquoi favoriser une structure, plutôt qu'une classe d'objet?
Est-ce pour l'avantage de la simplicité? (uniquement des champs/attributs et pas les méthodes, et les "problèmes de l'encapsulation?)

---

Tout à fait...

Disons qu'ici, nous serions vraiment dans le cadre d'une structure qui n'aurait absolument aucune autre responsabilité que... de faire tenir toutes les variables qui t'intéressent ensemble, bien qu'elles n'aient sans doute pas d'autres point commun que... de devoir être accessibles d'un bout à l'autre.

Tu pourrais, bien sur, utiliser une classe, et pousser l'encapsulation au point de placer les différentes variables en accessibilités privée, mais cela t'obligerait à rajouter des accesseurs (getters) et des mutateurs (setters) ce qui contreviendrait, de toutes manières, à la loi demeter.

Dés lors, autant ne pas mentir sur les termes clairement faire passer cette structure pour ce qu'elle est : un tas de données pas forcément ordonées (a bunch of data ) ;)

Citation:

---

Peut-on placer ce qu'on veut dans une structure?
A savoir, des variables "habituelles", mais aussi par exemple des tableaux, listes, ou maps dynamiques d'objets persos?

---

Ouait, strictement tout ce que tu veux, et meme des fonctions, si tu veux :D

Citation:

---

En utilisant ce fonctionnement, je devrais donc déclarer la structure au début, par exemple dans le premier module.

---

Tout à fait ;)

Citation:

---

Pourrais-je créer une fonction initialise(datas), qui initialiserait les champs de cette structure, séparément de la déclaration? Ou faut-il forcément initialiser les champs dès la déclaration?

---

Il faut noter qu'une structure peut parfaitement disposer d'un constructeur prenant des arguments ;)

Par habitude, j'aime que mes variables soient au moins dans un état cohérent et clairement défini lors de leur création.

Au pire, cela signifie que tu lis / demande les informations nécessaires à l'initialisation de la structure avant de déclarer la variable, mais ce n'est, à bien y réfléchir, pas un mal : cela te permettra de déléguer d'avantage les responsabilités (vu que, de toutes manières, tu devras quand meme lire ou demander ces informations à un moment où à un autre ;))

Mais tu peux, effectivement, décider de laisser cette structure dans un état "invalide" jusqu'à ce que tu aies réuni l'ensemble des informations qui lui sont nécessaires ;)

Cependant, L'habitude qui consiste à faire en sorte que tes objets soient tout de suite valides et cohérents dés le moment de leur déclaration est une habitude qui évite bien souvent des soucis en permettant, justement, de n'avoir pas à se poser la question de "que reste-t-il à faire avant de pouvoir utiliser l'objet" ;)

Citation:

---

Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct MaStructure { int variable1; double variable2; objetx variable3; map<int, objety> variable4; };   struct datas;   initialise(datas) { variable1 = 2; variable2 = 3.1415926535; ... }

---

---

Ce n'est pas interdit, mais tu pourrais très bien le faire dans le constructeur aussi, surtout pour les constantes (telles que le PI que l'on remarque dans ton code ou le 2, meme si on ne sait pas à quoi il correspond, il semble destiné à être constant ;))

Effectivement, mes exemples de variables seraient plus judicieux en tant que constantes, mais l'idée était là.
Les choses se précisent, et finalement, une structure n'est qu'une classe publique.
Au lieu de la déclarer "quelque part", un peu n'importe où, je pourrais alors faire, comme pour les classes, un fichier .h et un fichier .cpp pour la définition de la classe? (ou seulement un fichier .h vu le peu code nécessaire...). Et ce fichier serait inclus dès le début, avec la structure crée et initialisée par un constructeur.

A priori la technique du fichier .h définissant la structure et du #include dans le main fonctionne.

Maintenant, comment faire pour passer la variable du type de la structure (créée dans le main), à la suite (fonctions, modules, etc...).

Suffit-il, dans ces fonctions, d'utiliser le nom de la variable pour qu'elle soit manipulée? Puisque cette dernière est publique.
Ou faut-il passer par un pointeur vers cette variable de type MaStructure? Et ainsi passer le pointeur à toutes les fonctions qui ont besoin de cette variable?

Personnellement, je transmettrait une référence sur la structure au constructeur des classes qui en ont besoin...

Cela donnerait quelque chose proche de
MyStruct.hpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#ifndef MYSTRUCT_HPP #define MYSTRUCT_HPP   /* la structure "fourre tout" */ struct MyStruct { Type1 blabla; Type2 truc; Type3 brol; };   #endif //MYSTRUCT_HPP

---

La première classe du premier module
Module1.hpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#ifndef MODULE_1_HPP #define MODULE_1_HPP // on utilise ici la capacité de faire des déclaration anticipées ;) struct MyStruct; class Module1 { public: Module1(MyStruct & structure); /* ...*/ void doSomething(); private: MyStruct & structure_; }; #endif // MODULE_1_HPP

---

Module1.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include "Module1.hpp" #include "MyStruct.hpp" Module1::Module1(MyStruct & structure):structure_(structure){}   void Module1::doSomething() { /* ...*/ structure_.truc = /* calcul évolué */ ; /*...*/ int i = structure.brol * structure.blabla /* ...*/ /*...*/ }

---

La délcaration anticipée permet au compilateur de savoir qu'il existe une structure de type MyStruct (selon l'exemple) et de ne pas s'inquiéter outer mesure.

Cela ne fonctionne cependant que lorsque tu utilises les références (éventuellement constantes) ou les pointeurs ;)

de plus,le compilateur doit savoir de quoi elle est composée dés le moment où tu veux accéder à son contenu, c'est la raison pour laquelle on inclus le fichier d'en-tête MyStruct.hpp dans le *.cpp

D'accord oui.
Donc le principe est à peu près celui auquel j'avais pensé.
La structure est définie à part, et on la déclare une seule fois pour tout le code, avant la première fois qu'on a à l'utiliser. Cependant, le fait de la mettre private ne va pas empêcher de l'utiliser par la suite ailleurs? Ou est-ce que cette entrave est justement contournée par les pointeurs?

Quelle est la différence entre les références et les pointeurs?
Puisque dans une utilisation courante (sans polymorphisme etc...), les deux reviennent au même: passer une adresse mémoire. Alors pourquoi utiliser 2 variables (une pour la variable, et une pour le pointeur *), alors qu'avec une référence on a directement uniquement la variable (&)?
Ou alors je me méprends totalement sur les 2 concepts?

Il faut savoir que, par défaut, le passage d'argument se fait par copie.

C'est à dire que, si un argument est transmis par valeur ( par exemple comme dans : void foo(Type argument) ), la fonction va utiliser une copie de l'objet transmis, et que les modifications qui pourraient etre apportée à l'argument au sein de la fonction appelée ne seront pas répercutées sur l'objet dans la fonction appelante.

Ainsi, avec un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

struct Struct1 { int i; int j; } void foo(Struct1 arg) { std::cout<<"dans foo :"; arg.i *=2; arg.j *=3; std::cout<<" arg.i = "<<arg.i<<" " <<"arg.j = "<<arg.j<<std::endl; } int main() { Struct1 s1; s1.i = 2; s1.j = 3;   std::cout<<"avant la fonction :"; std::cout<<" s1.i = "<<s1.i<<" " <<"s1.j = "<<s1.j<<std::endl; foo(s1);     std::cout<<"après la fonction :"; std::cout<<" s1.i = "<<s1.i<<" " <<"s1.j = "<<s1.j<<std::endl; return 0; }

---

affichera

Code:

---

1 2 3 4

avant la fonction : s1.i = 2 s1.j = 3 dans la foo :arg.i = 4 arg.j = 9 apres la fonction : s1.i =2 s1.j = 3

---

Pour que les modifications apportées à l'objet dans la fonction appelée soient répercutées dans la fonction appelante, il faut que l'argument de la fonction appelée agisse comme "un alias" de l'objet de la fonction appelante.

Pour ce faire, on dispose de deux possibilités :

• passer l'objet sous la forme d'une référence (ex void foo(Type & argument))
• passer l'objet sous la forme d'un pointeur (ex void bar(Type * argument)

La seule différence (hormis la syntaxe à utiliser) qu'il y a entre les deux solutions, c'est qu'une référence a une garantie d'existence de l'objet référencé, alors que l'objet référencé par un pointeur peut ne pas exister.

Toutes deux évitent la copie de l'objet passé en argument, mais la référence est un alias (une référence au terme générique du terme ;) ) de l'objet passé en argument, alors que le pointeur est une variable qui contient l'adresse à laquelle se trouve l'objet réellement utilisé ;)

En C++, on préfère, autant que possible, transmettre les arguments pour lesquels on veut éviter la copie (que ce soit pour que les modifications apportées dans la fonction appelée soient répercutées dans la fonction appelante ou simplement parce que la copie de l'objet est un processus qui peut couter cher en temps et / ou en mémoire) sous la forme de référence, éventuellement constante si l'objet ne doit pas être modifié par la fonction appelante, car, justement, elle présente l'énorme avantage d'offrir la garantie de l'existence de l'objet référencé.

De plus, les pointeurs sont souvent associés à la gestion dynamique de la mémoire, et l'on a tot fait, avec un pointeur, de se poser la question de savoir s'il faut ou non libérer la mémoire allouée quand on n'a plus besoin de l'objet :aie:

Le conseil qu'il vaut mieux retenir est donc : utilises les références (éventuellement constantes) chaque fois que possible et n'utilises les pointeurs que "quand tu n'as vraiment pas le choix" (par exemple : quand il se peut que l'objet n'existe pas ).

Dans l'exemple que j'ai donné dans mon intervention précédente, on on crée la variable de type MyStruct le plus tot possible (en fait, suffisamment tot pour pouvoir encore utiliser cette variable une fois que l'ensemble du processus est terminé, histoire, par exemple, de pouvoir faire un affichage final basé sur son contenu) et on la transmet par référence à toute classe qui a besoin de cette structure pour qu'elle puisse la manipuler à son aise ;)

D'accord, donc pour toutes mes fonctions qui utilisent des objets déjà existants, il faut que je passe des références, soit "normales" si les objets ont à être modifiés, soit constantes si je ne fais qu'utiliser les variables.

Et donc en déclarant la fonction comme ceci: void foo(Type & argument), pour utiliser la variable dans la fonction, il faut utiliser & argument ou argument?

argument, tout simplement

Tu dois utiliser void foo(Type & argument)si l'argument passé a vocation à être modifié dans la fonction et void foo(Type const & argument) si l'argument passé n'a pas vocation à etre modifié par la fonction.

A l'intérieur de la fonction, tu y accèdes, tout simplement, sous la forme de argument ;)

Merci pour tout! ;)

Citation:

---

Envoyé par koala01

Tu dois utiliser void foo(Type & argument)si l'argument passé a vocation à être modifié dans la fonction et void foo(Type const & argument) si l'argument passé n'a pas vocation à etre modifié par la fonction.

A l'intérieur de la fonction, tu y accèdes, tout simplement, sous la forme de argument ;)

---

Une autre question, pour appeler la fonction à partir d'ailleurs, en faisant: foo(argument) c'est bon?
Car avec foo(& argument), mon compilateur me renvoie une erreur.

Dans un développement "normal", il faut ainsi toujours passer par référence les arguments d'une fonction?

Citation:

---

Envoyé par Gm7468

Une autre question, pour appeler la fonction à partir d'ailleurs, en faisant: foo(argument) c'est bon?
Car avec foo(& argument), mon compilateur me renvoie une erreur.

---

En effet, le symbole & a l'inconvénient d'avoir deux significations:
Lors de la déclaration, c'est le symbole représentant une référence (c'est à dire un alias sur une variable existante (ex : foo(UnType /* const */& truc);)

Lors de l'utilisation, c'est l'opérateur "address of" qui permet de récupérer l'adresse à laquelle se trouve la variable pour l'assigner, par exemple, à un pointeur (par exemple : UnType * ptr = & mavar;)

L'avantage des références par rapport aux pointeurs est, outre la garantie d'existence de la variable référencée, que cela s'utilise exactement comme la variable elle-même, à la différence près, bien sur, qu'il n'y a pas de copie de la variable, et donc que toute modification apportée à une référence dans la fonction appelée sera répercutée sur la variable dans la fonction appelante.

Il faut donc écrire ton code sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10

/* soit la fonction suivante */ void foo(UnType /* const */ & argument); // la fonction attend une référence // sur un objet de type UnType /* elle serait appelée sous la forme de */ int main() { UnType maVariable; foo(maVariable); return 0; }

---

Citation:

---

Dans un développement "normal", il faut ainsi toujours passer par référence les arguments d'une fonction?

---

Presque...

Pour tous les types "définis par l'utilisateur" (comprend : toute structure, classe ou union), c'est très clairement préférable pour éviter la copie, qui peut êtrtre très couteuse en temps et en mémoire.

Pour les "types primitifs" par contre (comprend : char, short, int, long, long long, float, double, long double et leur pendant non signé, si d'application), cela n'a pas énormément d'intérêt car la copie est très rapide et ne demande pas beaucoup plus de mémoire que le mécanisme qui est mis en oeuvre pour obtenir une référence.

Par contre, si tu veux que les modifications apportées à un type primitif dans la fonction appelée soient répercutées sur la variable passée en argument dans la fonction appelante, il peut malgré tout s'avérer utile de le transmettre par référence ;)

Encore une fois une réponse claire et précise!
Dans me mil!

Merci ;)

Je reviens encore une fois à la charge avec de nouvelles interrogations.

Au passage, j'en profite pour poser une "méta-question":
Toutes les interrogations que je poste sont en rapport direct avec le titre du sujet et mon projet, que j'explicite depuis le début. Cependant, elles sont relativement diverses, et parfois très éloignées les unes des autres.
Si ces disparités sont trop grandes et que la création d'un nouveau post serait nécessaire, faites-le moi savoir ;)

Revenons au tout début de ce post, où j'avais présenté le but grossier de mon application. Ci-dessous une petite explication pour illustrer la notion de module, bien que ce ne soit pas mon application, les idées sont bien illustrées:
Imaginons un exemple un peu abstrait mais compréhensible: une chaine de production de pièces de métal quelconques.
Au départ on a la matière première, un bloc de métal dans une caisse, c'est l'objet Pièce (avec différents attributs poids, matériau...).
Le but est d'automatiser la production de la pièce, c'est-à-dire toutes les étapes qui vont transformer la matière première pour arriver à la pièce finale.
On a donc le cycle principal:

(Début)->|Module 1: Chercher Matière|->|Module 2: Chauffer|->|Module 3: Forger|->|Module 4: Bavures|->|Module 5: Rendu|->(Fin)

Le Module 1 correspond à l'action, par exemple effectuée par un bras robot articulé, de prendre le bloc de matière première et de le déposer sur le tapis roulant d'amenée au four. Le Module 2 fixe la température du four, la vitesse du tapis. Le M.3 prend le bloc fondu, le place sur une enclume et tape avec un marteau pour former la pièce. Le M.4 peaufine la pièce et le M.5 commande un bras en fin de chaine pour prendre la pièce finale et la placer dans une caisse, rangée.
Chaque module effectue donc des actions qui font évoluer l'objet (le même objet) au cours du cycle, et bien entendu ces différents modules sont eux décomposés en successions d'actions plus élémentaires (M.1: Détecter la pièce - Commander bras 1 vers la pièce - Commander bras 1 vers le tapis - poser la pièce de telle manière).
On remarque également que certaines de ces actions élémentaires sont utiles à plusieurs modules: la fonction Commander bras est nécessaire au module 1, mais le sera probablement pour les modules 3 et 5 également, elle sera donc placée à part, dans le "Module Transversal".
Voilà pour les notions de module, action...

Vous m'avez aidé jusque là à concevoir l'architecture des fichiers, en utilisant des structures pour les "variables globales" nécessaires partout, notamment les objets manipulés, ainsi que des namespaces pour séparer les fonctions des différents modules qui doivent pouvoir être appelées dans d'autres bouts de code. J'ai à peu près assimiler le tout et d'après les tests effectués, ca a l'air de fonctionner (j'aurais posé des questions sinon, et j'en reposerai encore ;)).

Voici mon nouveau problème: l'enchainement des modules/actions.

Dans un fonctionnement habituel d'un programme (en tout cas pour moi), on a un main, qui contient une succession de fonctions. Chacune d'entre elles peut appeler d'autres sous-fonctions, etc..., mais leur ordre est défini dans le code. C'est-à-dire qu'à l'exécution, une fonction b() placée après une fonction a() ne sera exécutée qu'une fois la fin de la fonction a() atteinte (avec un return ou au bout "}").
Rassurez moi, est-ce bien cela pour le moment?

Par conséquent, dans mon application, j'ai un module principal, dans le namespace Principal, qui appelle les fonctions Module1::module1(), Module2::module2() et Module3::module3(). Admettons:

Code:

---

1 2 3 4 5 6 7 8

namespace Principal{ void principale(){ Module1::module1(); Module2::module2(); Module3::module3(); } }

---

Les fonctions modulex() appelant elles-même des sous-fonctions...

Si ce que j'ai dit tout à l'heure est exact, module2() sera exécutée qu'une fois que module1() sera terminée.
Cependant, comment "matérialiser" programmatiquement cette fin d'exécution? Comme je l'ai dit tout à l'heure, quand on arrive au return ou au "}", la fonction est terminée, mais en revenant à l'exemple plus haut, pour l'exemple du bras:
- On envoie un ordre (par exemple par port COM), de déplacement.
- On arrive alors à la fin de la fonction qui demande le déplacement, cependant, ce dernier, qui prend du temps, n'est pas terminé lui, et donc la fonction suivante serait appelée alors qu'il ne faudrait pas...
- Il faudrait donc gérer la réponse du port COM du bras disant "je suis arrivé, passe à la fonction suivante".
Vous voyez le problème?

Je suis dans un programme C++ utilisant Qt, j'ai donc à disposition le système de signaux/slots. Seulement, comment utiliser cela pour dire au programme par exemple d'envoyer la requête de placement , et d'attendre que celui-ci se termine SANS bloquer le programme (qui doit réagir à la réception de données dans le port), puis de dire à la fonction mère que c'est terminé et qu'on peut passer à la suite?

J'ai vu qu'il existe une classe QThread, mais qui n'utilise a priori pas les signaux/slots. Son utilisation serait-elle judicieuse ici?

Mon problème est vraiment de mélanger à la fois le système de signaux/slots sans que cela bloque la réception, tout en empêchant le programme de passer à la suite tant que l'action n'est pas terminée, ou au moins pendant un délai défini (en cas d'erreur lors de l'action ou lors de la communication)...
Cela fait beaucoup de choses effectivement, mais on avance dans le projet c'est pour ca ;)

Merci!

C'est là que tu vas commencer à apprécier tous les bienfait de la délégation de responsabilités :D

Si tu veux bien, reprenons un peu depuis le début, pour être sur que l'on voit les choses de la même manière :D

Tu aurais des parties "métier" qui correspondent à tes différents modules:

• Module1 : s'occupe de préparer la matière première (pesée, mélange, concassage, ... le tout, sans doute subdivisé en différents modules :D)
• Module2 : s'occupe d'apporter la matière première au four
• Module3 : le four (chauffe la matière première)
• Module4 : s'occupe d'apporter la matière première chauffée à la forge
• Module5 : la forge
• Module6 : s'occupe d'apporter la pièce forgée à l'ébarbeuse
• Module7 : ébarbeuse
• Module8 : s'occupe d'apporter la pièce finie à l'emballeuse
• Module9 : s'occupe d'emballer la pièce finie
• Module10 : s'occupe de ranger la pièce emballée

Tu remarqueras que j'ai rajouté quelques modules intermédiaires par rapport à ceux que tu prévois, mais cela entre dans le principe de ce que l'on appelle la "délégation des responsabilités" :D

L'avantage, c'est que les modules 2, 4, 6 et 8 sont, en réalités, simplement différentes instances d'un module unique ;)

"Au dessus" de ces modules, tu aurais la partie Qt qui s'occupe de les manipuler:

• ManipulateurModule1 : s'occupe de manipuler le module1 (éventuellement subdivisé en Manipulateurpesée, Manipulateurmélange, Manipulateurconcassage, ... :D)
• ManipulateurModule2 : s'occupe de manipuler le module2
• ManipulateurModule3 : s'occupe de manipuler le module3
• ManipulateurModule4 : s'occupe de manipuler le module4
• ManipulateurModule5 : s'occupe de manipuler le module5
• ManipulateurModule6 : s'occupe de manipuler le module6
• ManipulateurModule7 : s'occupe de manipuler le module7
• ManipulateurModule8 : s'occupe de manipuler le module8
• ManipulateurModule9 : s'occupe de manipuler le module9
• ManipulateurModule10 : s'occupe de manipuler le module10

Le module1 présenteras sans doute des fonctions comme

• peser
• mélanger
• concasser
• ...

et pourrait être associé à différents états:

1. pesageEnCours (au moment où il pèse la matière première)
2. pesageFini (au moment où il a fini de peser)
3. melangeEnCours (au moment où il mélange la matière première)
4. melangeFini (quand il a fini de mélanger)
5. concassageEnCours (quand il consasse la matière première)
6. concassageFini(quand il a fini de concasser la matière première)
7. enAttente (quand il est près à refaire un nouveau cycle (ce qui signifie : quand la matière première qu'il a préparée dans le cycle précédent a été retirée de ses bacs :D )

Les modules 2, 4, 6 et 8 auraient des fonctions comme

• prendre
• déplacer
• déposer
• retourPositionAttente

et seraient associés à deux états:

• libre (ils ne sont pas occupés à déplacer quelque chose)
• enCharge (ils sont en cours de déplacement)

Le module3 présenterait des fonctions proches de

• ouverturePorteEntree (pour pouvoir recevoir la matière à chauffer)
• fermeturePorteEntree (une fois que la matière est dépposée dans le four)
• preparationALaChauffe (tout ce qui doit être fait pour assurer que la chauffe se passe bien (création de l'atmosphère artificielle, vérification des pressions, des valves, calcul de la température optimale et du temps de chauffe, ...)
• chauffe
• ouverturePorteSortie (pour permettre de venir prendre la matière chauffée)
• fermeturePorteSortie (une fois que la matière chauffée a été sortie)

et serait associé à des états comme

• PorteEntreeOuverte
• PorteEntreeFermee
• PreparationEnCours
• ChauffeEnCours
• PorteSortieOuverte
• PorteSortieFermee
• EnAttente (quand il est près à refaire un nouveau cycle (ce qui signifie : quand la matière qu'il a chauffée dans le cycle précédent a été retirée de ses bacs et que la porte de sortie est fermée :D )

Les modules 5, 7 et 9 (respectivement la forge, l'ébarbeuse et l'emballeuse :D )présenterait des fonctions comme

• travailler

et serati associé à des états proche de

• TravailEnCours (tout le processus de forge, d'ébarbage ou d'emballage (selon le cas) :D )
• TravailFini (une fois que le processus est fini, mais tant que la pièce est encore dans la machine)
• EnAttente (quand la pièce est retirée et qu'on attend de recommencer un cycle)

L'avantage, c'est que Qt utilise un système de signaux et de slots assez intéressant ;)

Tu peux parfaitement lancer une étape en connectant le signal d'une des partie qui s'occupe d'un module particulier à un slot de la partie qui s'occupe du module suivant ou du module précédent :D

Les différentes parties de Qt qui s'occupent de gérer les modules vont envoyer à la partie qui s'occupe du module suivant et / ou à celle qui s'occupe du module précédant des signaux chaque fois que l'état du module change.

De même, les différentes parties de Qt disposeront d'un certain nombre de slots auxquels viendront se connecter les signaux envoyés par la partie qui s'occupe du module suivant et / ou par celle qui s'occupe du module précédent

Chaque slot aura pour responsabilité, en fonction de l'état du module précédent et du module suivant, de lancer une fonction du module dont la partie a la charge ou de mettre l'action en question "en attente" .

Tu pourrais donc avoir un tableau signal émis / réaction proche de (*)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Emetteur | signal | quand | recepteur | réaction | condition (**) ------------------------------------------------------------------------------------- Module2 | lache | dans module | module | lancer process | module pret Module4 | | suivant | suivant | (***) | Module6 | | | | | Module8 | | | | | ------------------------------------------------------------------------------------- Module3 | porte IN |porte In ouverte | Module2 | déposer | Module2 en charge | ouverte | | | | ------------------------------------------------------------------------------------- Module3 | porte OUT |porte OUT ouverte| Module4 | prendre | Module4 en attente | ouverte | | | | ------------------------------------------------------------------------------------- Module1 | process fini | module | module | prendre | module et Module5 | | suivant | suivant | |module suivant Module7 | | | | |pret Module9 | | | | | ------------------------------------------------------------------------------------- Module2 | pret | pret | module | prendre note | module pret Module4 | | | précédent | | Module6 | | | | | Module8 | | | | |

---

NOTA:
(*)Il n'est pas impossible que d'autres signaux doivent être émis en temps utiles, n'hésite pas à adapter ce tableau à tes besoins réels ;)
(**)Les conditions sont données à titre indicatif et devront très certainement être adaptées à la réalité du terrain:

Ainsi, il n'y a sans doute pas de mal à ce que les modules 2, 6 et 8 attendent en charge près du module dans lequel ils doivent déposer leur marchandise que le module ait fini.

Par contre, il vaut sans doute mieux attendre que la forge soit prête à recevoir la matière à manipuler avant meme d'ouvrir la porte de sortie du four, pour éviter que le four ou la matière ne refroidisse trop.

En outre, il sera peut etre aussi intéressant de lancer les signaux un peu avant que le module n'atteigne effectivement un état donné, pour prendre en compte les temps de déplacement et optimiser ainsi les temps d'attente ;)
(***)N'oublie pas que chaque process complet peut etre subdivisé en différentes étapes qui peuvent chaque fois nécessiter un état particulier de la part du module précédant ou du module suivant ;)

Tu fais bien de reprendre depuis le début, vu que le projet est assez conséquent et a priori relativement complexe, il est effectivement nécessaire de s'assurer que les propos de chacun soient cohérents.

Je pense que nous sommes en phase concernant le fonctionnement général, qui est maintenant plutôt clair.

Concernant les enchaînements, je pensais également à cela. Si je récapitule correctement, j'aurais d'un coté mes fichiers .h/hpp et mes fichiers .cpp qui correspondent à la partie métier, et contiennent les fonctions dans des namespaces, uniquement C++ ou BOOST, et qui décrivent les actions; et d'un autre coté leurs pendant Qt, qui s'occupera de l’enchaînement et du contrôle du bon fonctionnement de la partie métier?

Maintenant une question plus spécifique au module de communication, qui s'occupera de la réception des données par le port COM.
Imaginons que le tapis, le four, etc, soient branchés sur le port COM (en réalité il en faudrait probablement plusieurs, mais peu importe). Quand le programme envoie l'ordre "Faire avancer le tapis de 1 mètre", le module du tapis doit prendre le relais, le faire avancer, et renvoyer une réponse de la bonne exécution. Le programme réceptionne donc cette réponse, la traite, et si l'exécution est ok, envoie l'ordre suivant, par exemple ouvrir le four.
Comment procéder pour cet enchaînement? A nouveau avec les signaux/slots?

Et maintenant, compliquons un peu le problème, la communication peu être défectueuse, ou présenter des problèmes passagers, ou encore l'action peut ne pas être effectuée correctement. A ce moment, il faut qu'on gère le problème.
Par exemple, quand on envoie un ordre, toujours l'ordre "Faire avancer le tapis de 1 mètre" par exemple, la première solution pour continuer est de recevoir la réponse "ok". Mais si jamais la réponse contient autre chose, on relance l'ordre par exemple. Ou encore, si jamais la réponse n'est pas reçue au bout de 10 sec, on relance aussi l'ordre.
Le système de signaux et slots doit devenir sacrément compliqué non?
Puisqu'à mon avis, il faudrait en plus que je connecte et déconnecte des signaux et des slots lors de l'exécution pour qu'une fois tel signal déclenche tel slot et que si un problème survient, il en déclenche un autre?
Comment gérer également cette "temporisation", qui n'en est pas une, puisque le programme ne bloque pas pendant cette tempo, il attend la réception, et si cette dernière n'est pas arrivée en bout de tempo, alors tel signal est envoyé.

Est-ce que le problème exposé est suffisamment clair/pertinent?

Tu dois considérer le système de signal comme un "communication" (j'ai fait ceci", "il m'arrive cela" ou encore "j'ai terminé telle chose") émise par "n'importe qui" en direction de "toute chose concernée".

A charge pour "la chose concernée" par un signal de s'y connecter afin de pouvoir y réagir ;)

La réaction à un signal reçu peut, bien évidemment, dépendre du signal en lui-même, mais aussi de l'état dans lequel se trouve la chose qui le reçoit :D

Et tu n'est absolument pas limité ni dans le nombre de message qu'un objet peut envoyer, ni dans le nombre d'objets susceptibles de recevoir le message, ni même du point de vue du moment où un message est émis.

En effet, si un objet dispose d'un signal "jeMeVautre", tu peux décider d'émettre ce signal à n'importe quel moment, dans n'importe quelle fonction de la classe en question par un emit(jeMeVautre);et les objets qui sont susceptibles de réagir à ce signal seront automatiquement tenue au courent ;)

Alors, reprenons l'exemple du tapis roulant qui amène la matière première au four.

La partie qui gère le tapis roulant va invoquer la fonction "avancer" du module et peut, par exemple, lancer un timer qui permet de s'assurer d'une réponse adéquate dans les XXX secondes ;)

Le module va envoyer l'instruction correspondante par le port COM, et va renvoyer le résultat de la commande (si tant est qu'il la reçoive).

Il y a donc deux solutions: soit la partie qui gère le module obtient une réponse avant que le timer n'ai décrété un timeout, soit elle n'obtient pas cette réponse.

Dans le premier cas, la partie qui gère le module peut décider d'émettre un signal en fonction de la réponse qu'elle a obtenu, par exemple:

• un signal "j'attends la suite" si la réponse est positive ou
• un signal "j'ai eu un problème" si la réponse est négative

Elle peut aussi décider de faire d'autres choses en fonction du résultat obtenu, bien sur :D


Dans le deuxième cas, elle peut réagir de manière diverses, comme, simplement renvoyer l'instruction ou lancer un signal de type "je me vautre" ou encore... vas savoir ce qu'elle peut avoir à faire ;)

Les signaux qu'elle va émettre, elle va se contenter de les émettre (voir, si besoin, de réagir à un signal qu'elle aurait elle-même émit :D), à charge des "parties concernées" par le signal de réagir en conséquence ;)

Ainsi, le signal "j'attends la suite" sera sans doute connecté à un slot "ferme la porte" de la partie qui gère le four, et ce slot invoquera la fonction adéquate du module, qui enverra l'instruction en question au four par port COM, ainsi que par la partie qui s'occupe du module précédent qui l'interprétera comme un "Go" pour envoyer la suite ;)

Les signaux "j'ai un problème" et "je me vautre" peuvent, quant à eux, être récupérés d'une part par l'application (de manière générale) qui se chargera, par exemple, d'afficher un message d'erreur et / ou par la partie qui s'occupe des modules de sécurité d'autre part.

La partie qui s'occupe des modules de sécurité pourrait quant à elle, par exemple, en réaction, parfaitement, mettre en route une lumière rouge sur un poste de commande ou dans une allée ou activer une sirène en fonction de la gravité du problème ;)

Une petite précision encore:

A priori, le seul cas où tu devras déconnecter un signal, c'est si tu décide de détruire l'objet "récepteur" alors que l'objet "émetteur" continue d'exister, pour éviter que le signal ne soit émis vers... quelque chose qui n'existe plus :aie:


Dans l'autre sens, si l'émetteur est détruit alors que le récepteur continue à exister, il n'y a strictement aucun problème : le slot reste simplement ouvert (et sera fermé lors de la destruction du récepteur), meme si aucun signal ne parviendra plus jamais par ce biais ;)

Autrement, une fois qu'une connexion a été effectuée, il n'y a strictement aucune raison de supprimer cette connexion ;)

Ce que tu dois simplement faire, c'est, au niveau du slot, vérifier si le récepteur est en état d'avoir la réaction attendue au signal.

En fonction de l'état du récepteur, tu pourras décider de le faire réagir de la manière attendue ou de le faire réagir de manière à mettre les autres en attente (par exemple, en emettant un signal "n'en jetez plus" :D)

D'accord, je vois tout à fait le fonctionnement.

Le système des signaux et slots est réellement quelque chose de très puissant, mais il me semble quand même que, dans mon cas, cela va être difficile à mettre en oeuvre. Du moins au moins à concevoir, car j'ai une foultitude des signaux et slots qui vont devoir être créés, mais au moins tu m'as apporté la solution ;)

Je vois également le fonctionnement que tu me proposes. Il ne faut pas que je déconnecte les liaisons, mais que je crée suffisamment de membres dans les classes correspondantes pour gérer tous les cas que je veux, et ainsi émettre les bons signaux quand il faut pour déclencher les bons slots.

Le timer dont tu parles m'intéresse particulièrement: j'ai fait des recherches et j'en trouve beaucoup qui, d'après ce que j'ai compris, bloquent le programme. Y a-t-il un timer dans Qt qui ne bloque pas les autres processus? Question sous-entendue: est-ce que le QTimer de Qt (qui dispose du signal "c'est fini") bloque le reste de l'exécution?

En XP (Xtrem Programming), il y a deux vocables dont tu peux t'inspirer: YAGNI (You Ain't Gonna Need It, ou, si tu préfères, "Tu n'as pas encore besoin de ca") et KISS (Keep It Simple, Stupid, ou, si tu préfères, "Garde cela simple, stupide").

Il ne sert à rien d'essayer de prévoir tous les cas de figure et tous les signaux qu'une de tes classes est susceptible d'émettre, ni tous les slots qui sont susceptibles de les récupérer ;)

Contente toi d'émettre un signal de début et un signal de fin (on pourrait dire "contente toi du cas de base") dans un premier temps

Une fois que tu obtiens quelque chose qui fonctionne, intéresses toi à ce qui peut faire que cela ne fonctionne pas, et, s'il y a une information à faire passer entre les modules, détermine quelle message doit etre envoyé et qui doit le récupérer ;)

Tu étofferas ta liste de signaux "au fur et à mesure", et sans de casser la tête ;)

Quant à QTimer, ce n'est pas une simple fonction sleep (qui est effectivement bloquante), et, pour autant que je sache (mais bon, je n'exclue absolument pas de me tromper), QTimer n'est pas bloquant ;)