Discussion :

[DEVfan]

Bonjour,

Le sujet est peut-être déjà paru mais impossible de faire tourner le moteur de recherche du forum (qui a éteint la lumière?!)

quand je fais des classes en c++, généralement, je mets tout dans un header si c'est vraiment minimal et sinon, je partage déclaration et définition dans un fichier .h et un fichier .cpp. Et l'include du .h dans les fichiers qui utilisent la classe appellée
Jusque là, pas de pb...

J'utilise maintenant Qt... et parfois certaines organisation ne sont pas acceptées!

ex1 : j'ai pas le droit de définir après la déclaration totale de la class dans le fichier header
ex2 : je dois faire un include du .cpp que j'utilise dans les .cpp qui l'exploite

... et avec des fichiers en cascade, je peux pas compiler.
Existe-t-il une organisation type qui marche à tous les coups?! (un standard quoi!)

[zais_ethael]

Ça m'a plutôt l'air d'être un problème lié à Qt, pour ça il y aura bien un initié sur le forum pour répondre.
Sinon comme bonnes pratiques pour les cas généraux je pourrais rajouter:
- toujours définir un namespace pour ton projet et mettre toutes tes définitions dedans, même pour de tous petits projets ils peuvent finir par s'exploiter l'un l'autre et on en comprend vite l'utilité
- pour les fonctions/classes à usage interne (définis uniquement dans un fichier .cpp parce que on en a pas l'utilité ailleurs), toujours les englober dans un namespace non nommé pour éviter des problèmes de link (rarissimes mais pas inexistants)
- les extensions .h en C++, ça craint. Plusieurs bibliothèques ont choisi d'adhérer à la norme utilisée par boost: les .hpp. Ça permet de bien séparer les fichiers C des fichiers C++ (ça n'a rien à voir!!)

[coyotte507]

Salut, une question:

Quand tu dois inclure les cpp, c'est les cpp de Qt, ou alors les cpp de ton projet?

[Davidbrcz]

Avec Qt, tu peux quand même définir entièrement certaines classes dans les headers, mais il faut inclure le fichier moc de la classe ou un trcu du genre dans tes sources.
Je m'en vais rechercher ca.

[DEVfan]

merci d'avance pour la recherche sur le moc ou truc comme ça

Pour répondre à la question, c'est les cpp de mon projet... en fait, j'observe plein de différence entre des configurations à compilations qui marchent et des configurations à compilations qui marchent pas... que je sois en projet C/C++ exclusivement ou projet Qt par exemple.

ok pour les namespace. Je faisais ça avant mais c'est parfois un peu lourd quand on utilise plusieurs namespace dans un même fichier.
.h et .hpp ... j'utilisais ça aussi avant... et je sais plus pourquoi j'étais revenu au .h Je vais tester ça même si Qt semble ne pas en avoir (de .hpp)

Encore un truc : j'utilise la règle suivante pour choisir si je mets les include dans le .h ou le .cpp, est-elle correct?
Je fais l'include dans le .h que si un appel y est fait. Je fais l'include dans le .cpp que si c'est pas dans le .h (normal) et que au moins un appel est fait (normal aussi)
Par contre pour les include de .cpp ... j'ai pas encore trouvé de truc logique et efficace. Avant, j'en mettais jamais mais là, il se trouve que j'en ai eu besoin pour que le compilo me dise oui. Avez-vous une petite règle à ce sujet (même maison)?!
EDIT : il semblerait que mettre include des .cpp qui sont appelles dans le cpp qui s'en sert... soit une solution.

[coyotte507]

Salut,

franchement ton problème est bizarre, je ne connais pas Qt mais quand même...
Je pense aussi que comme zais_ethael le dit, ça a à voir avec Qt, donc peut-être que si tu vas sur le forum de Qt on pourra t'aider

[yan]

Salut,

franchement ton problème est bizarre, je ne connais pas Qt mais quand même...
Je pense aussi que comme zais_ethael le dit, ça a à voir avec Qt, donc peut-être que si tu vas sur le forum de Qt on pourra t'aider

Ben même pour du Qt c'est carrément bizzare.... Première fois que j'en entend parler....
A moins qu'il ne compile pas les fichier généré par moc, je ne voit pas pourquoi il mettrais des .cpp dans ses .cpp
Peut tu mettre un exemple simple????

[Mat007]

Salut,

J'utilise pas mal Qt (imposé) et oui quand on moc un .h on a le .cpp qui commence toujours par :

Code :

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

1
2
3
#include "Some.h"
#include "moc_Some.cpp"
...

Ca évite de polluer la liste des fichiers de l'IDE avec tout un tas de fichiers générés (qui des fois existent et des fois non, ne sont pas générés au même endroit que les sources, etc..).

Cela dit je n'ai pas vraiment vu d'autre "problème", il y a quelques micro-subtilités (par ex ne pas nommer un paramètre slot) mais à part ça c'est du C++ tout ce qu'il y a de plus "normal".

MAT.

[yan]

???
pourquoi mettre les moc**.cpp dans les .cpp???
vous avez vue un intérêt de faire ca pour quel compilot????
Vous n'avez jamais utilisé qmake?

[Mat007]

pourquoi mettre les moc**.cpp dans les .cpp???

Pour ne pas avoir à dire au compilateur/IDE de s'occuper des moc_*.cpp

vous avez vue un intérêt de faire ca pour quel compilot????

C'est pas réellement un problème de compilateur (techniquement le compilateur compile les fichiers que tu lui dis de compiler), mais plus d'IDE.
En pratique on utilise surtout Visual Studio sur les postes de développement et des scripts (basé sur ant et cpptasks) sur les serveurs de compilation continue.

Vous n'avez jamais utilisé qmake?

C'était déjà fait comme ça quand je suis arrivé dans ma boite (avec du Qt 3.x) et j'avoue n'avoir jamais regardé s'il y avait plus simple.
Cela dit de ce que j'en avais vu qmake est un nième clone de make qui colle des fichiers de configuration partout dans l'arborescence des sources, et vu que Qt ne représente que quelques pourcents de nos développements ça me ferait un peu mal de lâcher plus que nécessaire à cette usine à gaz déjà bien trop intrusive à mon goût.

Donc oui actuellement c'est un coup de moc en custom build sur le .h et un #include "moc_*.cpp" dans le .cpp, et voilà.
Si tu vois mieux, ça m'intéresse !

MAT.

[yan]

Donc oui actuellement c'est un coup de moc en custom build sur le .h et un #include "moc_*.cpp" dans le .cpp, et voilà.
Si tu vois mieux, ça m'intéresse !

Je mettais tous les fichiers générés dans un sous répertoire virtuel du projet visual pour ne pas mélanger.
Aprés je ne sait pas si c'est bien judicieux d'inclure les moc**.cpp dans des *.cpp
je vais me renseigner

[DEVfan]

et bah... c'est une question de fond!

Ben merci déjà de me dire que c'est normal, je craignais avoir fait qq chose de louche!
Et de merci de vous creuser la cervelle por simplifier ce petit foutoire.

[yan]

Donc oui actuellement c'est un coup de moc en custom build sur le .h et un #include "moc_*.cpp" dans le .cpp, et voilà.

Apparemment tu risque juste de se retrouver avec des problèmes au link avec des duplications de symboles.

Si tu vois mieux, ça m'intéresse !

Si c'est bien séparé, tu génère tes .dsp pour la partie IHm avec Qmake ou tu utilise l'integration de Qt pour ajouter tes fichiers dans visual

[DEVfan]

C'est quoi les .dsp? J'ai pas visual aussi

[yan]

C'est quoi les .dsp? J'ai pas visual aussi

.dsp(VC6), .vcproj(VC 2003 etsuperieur) sont les fichier projet au format visual.
A mon avis , il est tout de même préférable d'utiliser qmake pour générer les makefile/"fichier projet" associé à la partie Qt.

[Mat007]

Apparemment tu risque juste de se retrouver avec des problèmes au link avec des duplications de symboles.

C'est bon parce que les moc_*.cpp ne sont pas compilés, juste inclus.

Si c'est bien séparé, tu génère tes .dsp pour la partie IHm avec Qmake ou tu utilise l'integration de Qt pour ajouter tes fichiers dans visual

Je ne vois pas bien l'intérêt de générer des fichiers lorsque je peux m'en passer...
A chaque fois que tu ajoutes un nouveau fichier que tu dois moc tu ré-invoques qmake, qui va donc re-créer le dsp/vcproj et t'obliger à tout recompiler ?

MAT.

[yan]

Je ne vois pas bien l'intérêt de générer des fichiers lorsque je peux m'en passer...

?? ben les moc doivent bien etre genéré??
Je ne garanti pas qu'il faille compiler les moc_**.cpp comme un .cpp quelconque. Je me méfierais.

A chaque fois que tu ajoutes un nouveau fichier que tu dois moc tu ré-invoques qmake, qui va donc re-créer le dsp/vcproj et t'obliger à tout recompiler ?

Tu le fait au pire une fois. Aprés tu utilise l'integrateur Qt de visual. il fera le boulot a ta place. Sans visual ca as plus de sens. Beaucoup plus simple de lister les fichier dans un *.pro. qmake fera le reste

[DEVfan]

Sans visual ca as plus de sens. Beaucoup plus simple de lister les fichier dans un *.pro. qmake fera le reste

...ok, c'est ce que je fais (en fait l'integration Eclipse le fait ... mais des fois, ça m****). Par contre, ça m'oblige toujours à mettre le include.cpp dans les .cpp qui s'en servent... ce qui est un peu déroutant quand on sort d'un cycle de développement C++ brut. Heureusement, on s'adapte à tout!

[yan]

. Par contre, ça m'oblige toujours à mettre le include.cpp dans les .cpp qui s'en servent...

??? c'est l'integration qt d'eclipse qui fait ca??

[DEVfan]

Bon, je reprends le topic que j'ai commencé...parce que le pb ressurgi à nouveau.

Je développe sous éclipse du C++... rien d'autres à déclarer pour le contexte utile!

J'ai une classe de base nommée A constitué d'un .h et d'un .cpp (un classique donc).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
#ifndef A_H
#define A_H
 
#include <algorithm>
using std::max;
using std::min;
 
class A
{//blabla};
 
#endif

Le .cpp fait simplement un #include "A.h" ...normal

Ensuite, j'ai une classe B qui est une aggrégation de A donc j'ai un B.h qui comporte un #include "A.h" et un B.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
 
#ifndef B_H
#define B_H
 
#include "A.h"
 
#include <vector>
#include <algorithm>
#include <math.h>
using std::vector;
 
class B
{
 vector<A> vectA;
//blabla
};

Le .cpp fait simplement un #include "B.h" ...normal que je pensais sauf que j'ai le droit à 2 erreurs (qui provienne d'une méconnaissance de A..) :
_erreur type1 : dans stl_iterator.h undefined reference to ...des méthodes de A.h
_erreur type2 : in fonction ...une méthode B.o mais avec des caractères et des chiffres en bonus (ex : 'ZN8maclasseB4AireEV') associé à des undefined reference de méthodes de A.h

Je me suis dis...il connaît peut être A.h mais pas A.cpp... aidons le!
le .cpp possède donc A.cpp et B.h (j'ai essayé les 2 sens possibles)
Ce qui donne les erreurs
_First defined here
_les méthodes B.o avec des chiffres et des lettres
_multiple declaration of ...méthodes de B.h

...et alors pourquoi pas dans le .h ?! ...et pareil!


QQ1 a-t-il une idée?
[Je précise que tout dans les .h ...donc cpp vide, ça compile bien... pour rassurer d'éventuels sceptiques!]
Merci d'avance.