Discussion :

[Gm7468]

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.

[koala01]

Salut, et bienvenue sur le forum

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

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 )

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"

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 )

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

[Gm7468]

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

[koala01]

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

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

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"

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

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

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

C'est effectivement ce qu'il faut faire

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

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é

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"

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

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

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

[Gm7468]

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

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.

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 ^^

[Gm7468]

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?

[koala01]

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++ ) 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[jean-eude06]

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.

[Gm7468]

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

[koala01]

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

[Gm7468]

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

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...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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!
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[koala01]

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

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

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

[Gm7468]

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?

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Gm7468]

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?

[koala01]

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

[Gm7468]

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!

[Gm7468]

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...)?
...?

[koala01]

Personnellement, je suis plutôt d'avis de limiter autant que possible (pour ne pas dire "de proscrire" )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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

[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?
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
...
}