Comment structurer mon projet c++

Bonjour,
Je viens du Java, je travaille sur un projet c++ et j'utilise Qt comme framework/bibliothèque. Je vous serais reconnaissant de me donner des tuyaux pour structurer mon projet. Je suis complètement perdu 8O avec les notions d'espaces de nom et de modules. Je voudrais par exemple éviter d'avoir un chemin (même relatif) trop compliqué dans mes sources du style:

Code:

#include "org/katitou/model/Trader.h"

ou un espace de nom du style:

Code:

using namespace org__katitou__model;

Je voudrais par contre imiter la structure de Qt qui permet d'avoir toutes les classes de QtGui avec la simple directive suivante:

Code:

#include <QtGui>

Vos suggestions sont les bienvenues...
Julien.

Ce n'est pas une marche à suivre, mais je vais simplement te dire ce que je fais personnelement :
* Je n'utilise pas d'espace de nom ( je n'ai pas encore trouver d'interet .. je m'arrange seulement dans mes noms de classes )
* J'ajoute mes directory directement dans la config du projet ( sous Visual Studio ) ( pour eviter les "X/Y/Z.h" )
* Pour les librairies externes, j'ajoute les path dans la config de VS ( pour des include de type <X.h> ( pour distinguer mes classes et celles des libs )

Merci pour ta réponse raptor70

Bonjour,

Je vais tenir compte du premier point de ta réponse et je n'utiliserai pas les espaces de nom.

Concernant les points 2 et 3, ceux-ci me semblent intéressant cependant je développe sous linux...

Quelqu'un a-t-il une autre idée sachant que je développe sous linux avec eclipse??

Merci d'avance,

Julien.

Tu travailles surement avec des makefiles. Dans ce cas, tu n'as qu'à rajouté dans les dossiers d'inclusions les dossiers d'en-têtes des bibliothèques que tu utilises. De même pour les dossiers du linker.

Ca te raccourcira pas mal les #include entre autres.
Pour les namespaces, je ne sais pas vraiment quoi te dire. Ceux de tes bibliothèques, tu n'as pas le choix.
Le fait que toi tu en utilises ou non, c'est un autre problème. Tu peux trouver pas mal de discussions sur les namespaces en faisant une recherche dans ce forum.

Salut,

En fait, l'équivalent en C++ serait plutôt de l'ordre de
Code:

1 2 3 4 5 6 7 8 9 10 namespace org { namespace katikou { namespace model { /*...*/ } } }
Si, de fait, l'idée de commencer par créer trois espaces de noms (dont un dans lequel on trouverait des milliers d'autres espaces de noms, correspondant au milliers de possesseurs d'un hébergement en .org et un dans lequel on retrouverait l'ensemble des projet d'une même personne/société/association), dans l'idée de ce qui se fait avec les paquetages de java me semble un peu excessive, il faut quand même se rappeler une limite qui existe dans tous les langages de programmation impérative, qu'il soient orientés objet ou non: un nom de type ne peut représenter qu'une et une seule chose.

Or, il faut quand même se rappeler, aussi, que le propre des langages de programmation est de fournir la possibilité de réutiliser des codes extérieurs: bibliothèques, ou applications existant en dehors du projet que l'on crée.

En effet, qu'il s'agisse d'utiliser la bibliothèque standard,boost, OpenGl, DirectX, un framework particulier ou une bibliothèque peu connue "du grand public" (pourquoi pas écrite par toi, il y a trois ans, parce que tu estimais utile de disposer de tels ou tels services/possibilités :question:), le recours à ces parties "externes" à ton projet est, pour ainsi dire, systématique.

Et c'est là que les problèmes commencent à apparaître...

Selon le but des types que tu crées, tu va les nommer, si possible de manière explicite.

Ainsi donc, si tu veux créer un type qui permet de représenter/gérer une personne, tu utilisera sans doute l'identifiant Personne de préférence à TrucMuch ou à BrolBidule...

Seulement, voilà... Dans tous les projets externes que tu utilise - parce que chaque bibliothèque ou framework que tu risque d'utiliser peut être considéré comme un projet, si pas comme un ensemble de projet (ex: boost) - il est possible que l'on aie voulu pouvoir aussi représenter/gérer une personne, très vraisemblablement en lui donnant des caractéristiques ou des capacités qui ne sont pas celles que tu aurait voulu mettre en avant pour ton type Personne à toi. Et, tout comme toi, il est à craindre qu'ils aient pensé tout naturellement à identifier leur type avec le terme Personne, de préférence à TrucMuch ou à BrolBidule :P:roll:

Le résultat est immédiat: si rien ne vient permettre de distinguer ton type Personne du type Personne de la bibliothèque externe, le terme Personne représente deux choses différentes (et ce, même si les membres et méthodes sont sensiblement pareils), et le langage, ne sachant plus où donner de la tête, est incapable de décider quand utiliser le type Personne de la bibliothèque externe et quand utiliser le tien.

Pire, même: Il est très régulier de voir un projet regrouper des capacités aussi diverses et variées que:

afficher quelque chose à l'écran (éventuellement au travers d'un framework)
récupérer/envoyer les données dans/vers une BDD
enregistrer les données dans un format quelconque sur le disque dur
envoyer les données à un autre ordinateur, via un réseau quelconque (et selon un protocole quelconque)
...

Toutes ces capacités ont un seul but: la transmission des informations permettant de gérer un objet donné.

Evidemment, si un type existe dans le concept de "gestion des objets", tu peux te dire qu'il existe un type équivalent pour chacune de ces capacités, et que ce type sera idéalement identifié par le même nom, avec, de nouveau, le problème d'ambigüité de l'identifiant.

En C, une habitude couramment observée est de préfixer l'identifiant du type par un terme représentant soit la bibliothèque d'origine, soit le but poursuivi par le type.

Ainsi, pour gérer notre type Personne, tu te retrouveras facilement avec des types tels que

SqlPersonne et peut être meme carrément

SqlQueryerPersonne
sqlUpdaterPersonne
FileWriterPersonne
NetSenderPersonne
NetReceipterPersonne
...

Et tu commence peut être à entrevoir les limites de cette habitude...

Le fait est que si ces noms de types sont clairement explicites quant à leur but final, on obtient rapidement des identifiants "à charnière et à rallonge", d'autant plus que je n'ai pas précisé la bibliothèque dont ils font partie, et que l'on pourrait donc carrément se retrouver avec un identifiant de type du genre de MaBelleBibliothequePersonnelleFileWriterPersonne :roll::roll:.

Un tel nom de type, pour explicite qu'il soit, devient rapidement impossible à utiliser dans un code... Ne serait-ce que à cause des risques de fautes d'orthographe qu'il représente :P

En plus, si tous les types doivent être en mesure de communiquer avec le type "de base" Personne, il n'est - a priori - pas nécessaire que tous ces types se connaissent les uns les autres: Le typeFileWriterPersonne n'a que peu à faire avec le type SqlQueryerPersonne, et réciproquement.

Or, si tu mets tout "dans le même sac", comme c'est le cas en C ou quand tu n'utilise pas les paquetages en java ou les espaces de noms en C++, tous ces types particuliers sont susceptibles d'aller *directement* "se chatouiller l'un l'autre", car il suffit que deux fichiers d'en-tête soient inclus en même temps pour le leur permettre.

C'est pourquoi les langages orientés objet ont décidé de fournir la possibilité de regrouper les différents types en fonctions de leurs utilité finale et de les empêcher de voir les types qui se trouvent dans "les autres sacs".

Cette possibilité est fournie par les espaces de noms, que l'on connait en java sous le terme package et en C++ sous le terme namespace.

Cela n'interdit pas au type se trouvant dans l'espace de noms réservé à la gestion SQL "d'aller châtouiller" un de ceux qui se trouve dans l'espace de noms réservé à la gestion réseau des informations, mais ca place néanmoins un "garde barrières" entre les deux.

Ainsi, il semble opportun de créer ne serait-ce qu'un espace de noms pour ton projet, de manière à éviter les ambigüités avec "tout ce qui est extérieur" à ton projet, et il serait de bon ton d'envisager de séparer les "grands objectifs finaux" au sein de cet espace de noms commun.

Au final, tu obtiendrait une arborescence du genre de

espace de noms de ton projet

Personne
espace de noms réservé à la gestion SQL

PersonneQueryer
PersonneUpdater
espace de noms réservé à l'écriture dans les fichiers

PersonneWriter
espace de noms réservé à la gestion réseau

PersonneSender
PersonneReceipter

ET si donc, bien que ce ne soit pas le cas dans cet exemple, un identifiant venait à être utilisé au sein de différents espaces de noms, ce serait alors l'espace de noms qui fournirait le contexte d'utilisation permettant d'éviter l'ambigüité ;)

C'est une très mauvaise idée de ne pas utiliser d'espaces de nom et l'explication détaillé de koala01 en est la preuve :king:
Sinon comme tu développe en c++ sur linux je me suis dit que tu pourra utiliser easyeclipse comme outils de développement sinon y en a plein d'autres : KDevelop, eclipse avec le C/C++ Development Tools ou tout simplement Emacs ;)