Discussion :

[giova_fr]

Bonjour.

Je ne m'en sort vraiment pas avec ces includes, a chaque projet, c'est la meme chose, je galere pendant des heures, typiquement aujourd'hui, ca fait 3 heures que je lutte, je ne comprends pas pourquoi ca ne marche pas, et le patron finit par faire la gueule.

Donc j'aimerai une bonne fois pour toute maitriser le sujet, je suis pret à payer un cours particulier si il le faut (en region parisienne), mais je ne peux plus continuer ainsi. Je verrai bien le cours se dérouler ainsi : 1/2H de theorie, explication des mecanismes, comment utiliser judicieusement les pragma once, les ifndef, où placer les includes de quoi de qui et comment. 1/2H de pratique sur visual charpente d'appli MFC, je ressortirai 2 projets où j'ai tout particulierement galeré avec ces maudits includes.

[la drogue c'est mal]

bah c'est pas tres compliqué, pas besoins de cours particulier payant :

pour faire simple:

include: inclure.

lorsque tu fais #include "stdafx.h" dans un fichier, c'est comme si tu faisais un gros copier coller du contenu de stdafx.h dans ton fichier.

Générallement on met dans les fichiers .h des déclarations :
- variable globale
- type de donnée (typedef, enum, class etc...)
- de constante (variable de type const, #define)
- des fonctions

en fait tu peux mettre tout et n'importe quoi. C'est à toi d'etre structuré.

Comment s'en servir :
- deja evite le plus possible (dans la mesure du possible) de mettre des #include dans des fichiers .h
Pourquoi ? car tu risques d'avoir des dépendances circulaires.

Par exemple:

pour reprendre l'image du copier/coller:

dans A.h tu mets #include "B.h"
dans B.h tu mets #include "A.h"

dans A.h tu fais un copier/coller du contenu de B.h mais dans B.h tu fais également un copier/coller du contenu de A.h dont le contenu dépend de B.h

tu vois l'embrouille ???

Ensuite, il faut savoir que tu ne dois avoir qu'une déclaration unique de ce que tu déclares dans tes .h.
C'est une evidence vu tu ne peux pas avoir 2 déclaration de class CToto dans un projet

les fichiers étant compilés séparement, à chaque fois que tu fais un #include dans un fichier .cpp, le compilateur reprend à chaque fois le contenu du .h (le fameux copier/coller) et compile. Jusque la tout va bien jusqu'a l'editeur de lien.

L'editeur de lien est la pour dire """si toutes les déclarations sont compatibles entre eux""" et si tu ne fais pas attentions, il te dit que tu as des doubles déclarations (machin already declare in blabla)

exemple :
dans A.h tu as : class ClassUnique

dans Fichier1.cpp tu fais #include "A.h" => compilation de A.h dans Fichier1
dans Fichier2.cpp tu fais #include "A.h" => compilation de A.h dans Fichier2

le compilateur va bien compiler
le link va te dire que ClassUnique est deja défini dans Fichier1

Pour palier ce probleme, tu as 2 solutions:
1) solution "non standard" mais qui fonctionne tres bien sur VC6:

tu mets #pragma once au debut de ton fichier .h

ca dit au compilateur qu'il doit compiler qu'une seule fois le contenu du .h (once == UN)

2) solutions standard :

#ifndef MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET
#define MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET

#endif MA_BALISE_A_MOI_ET_UNIQUE_DANS_MON_PROJET

explication:

#ifndef MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET :

debut d'une procédure de if + Si MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET n'existe pas (ifndef == if not define) alors je fais tout ce qu'il y a en dessous jusqu'a la fin de la balise de fin de Si


#define MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET : je declare MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET


#endif MA_BALISE_A_MOI_ET_UNIQUE_DANS_MON_PROJET : fin de la procédure de if

ce qui au niveau algo donne :
si machin n'existe pas
-> le faire exister (le déclarer quoi)
fin si

ce qui en concret donne dans un fichier .h

Code :

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

1
2
3
4
5
6
7
8
9
 
// La premiere ligne de ton fichier .h
#ifndef MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET
 
// La deuxieme ligne de ton fichier .h
#define MON_DEFINE_A_MOI_ET_UNIQUE_DANS_MON_PROJET
 
// La derniere ligne de ton fichier .h
#endif MA_BALISE_A_MOI_ET_UNIQUE_DANS_MON_PROJET

ce que ca va faire au niveau du compilo:

dans A.h tu as : class ClassUnique avec un ifndef

dans Fichier1.cpp tu fais #include "A.h" => compilation de A.h dans Fichier1
dans Fichier2.cpp tu fais #include "A.h" => PAS DE compilation de A.h dans Fichier2

Comment utiliser les .h ?

bah c'est simple, tu ajoutes un .h dans tes fichiers quand tu as besoins du contenu (le fameux copier/coller)

c'est pas tres conventionnel comme explication, certains vont peut etre hurler (et je le comprendrais) mais ca devrait t'aider à comprendre

[giova_fr]

Merci ma drogue d'avoir pris le temps de m'expliquer tout ca, dans un sens tu me rassure un peu, car j'avais bien compris l'utilisation de #ifndef.

Malheureusement j'ai des cas où cela ne fonctionne pas bien. Je me rappelle d'un projet où dans un .h je fesais un

#ifndef TOTO
#define TOTO

declaration d'une classe
déclaration d'un thread

#endif

quand j'incluais ce header dans plusieurs fichiers sources, le linker me disait que le thread etait deja déclaré, et pourtant il etait dans le ifndef, et pourtant la classe elle ne posait pas de probleme. AU final, j'ai du en faire un membre static de ma classe pour palier le PB, mais je n'ai jamais compris le pourquoi du comment.

La ou je lutte pas mal aussi c'est quand j'ai une classeA qui a besoin d'etre connue dans plusieurs header car ces header definissent des classes comportant un membre de type ClasseA. Si pas de #ifndef ca me dit que ClasseA est deja declaré, si #ifndef, ca me dit que le type ClasseA n'est pas reconnu. Bref , je m'arrache les cheveux.

Hier j'avais des soucis de Runtime lié a mes includes, et comme je debute avec les MFC, j'ai passé 4 Heures a essayer de comprendre, mais en vain

Enfin, j'aimerai comprendre pourquoi des fois on vois dans des header des #pragma once ainsi que des #ifndef. Pourquoi les deux? quel est le role de #pragma once dans ce cas exactement et précisement? doit on le mettre dans le #ifndef? avant? apres? bref, je suis noyé.

Je vais passer ce samedi a concocter des exemples basiques de headers qui font que je serai bientot chauve, et je vous les soummettrait.

En tout cas merci encore pour tes explications.

[giova_fr]

pour info, j'ai enfin trouvé le pourquoi de mon probleme de runtime error.

il etait lié à visual 2005 (RTM.050727-4200). J'avais utilisé la toute nouvelle fonctionnalité qui permet dans l'explorateur de solution de visionner tous les fichiers présents dans le répertoire (voir image). Et depuis cette vue j'avais cliqué sur le header et code source de la classe qui m'interréssait, puis dans le menu contextuel fait "add to project".



apres avoir perdu des heures et des heures, (et beaucoup de cheveux) j'ai retiré ces fichiers de mon projet, fait un bon vieux add, existing item, j'ai reselectionné ces fichiers, et là oh miracle, j'ai pu linker .

Bref je ne suis pas pret de réutiliser cette fonctionnalité visual de sitot. Et n'empeche que je suis malgres tout, toujours prenneur pour un court approfondi sur l'art de faire des includes.

[giova_fr]

Non vraiment par pitié A L'AIDE !!!!!!!!!!!!!!

vraiment je ne m'en sort pas avec ces include, c'est la croix la banniere !!!

Aujourd'hui je rajoute dans un couple .h .cpp une fonction, et boom ca ne link plus, je retire cette fonction (donc reviens à l'etat initiale) et non ca ne veut plus linker, vraiment je suis totalement perdu !

Bon... concretement, voici mon cas d'aujourd'hui :

Je veux faire une classe exploitable dans plusieur projet, appellons la CTool. ET je veux :

1) pouvoir utiliser CTool dans d'autre projet, sans avoir a modifier constament son header.

2) que le fait d'inclure cette classe dans un projet m'annonce pas "Cbidule est deja défini dans CTool"


CTool a besoin dans son header d'une autre classe CGenerique car elle possede un membre de type CGenerique.

Code :

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

1
2
3
4
5
6
Classe CTool
{
public:
 
   CGenerique m_generique;
}

Je suis sous mfc et ma boite de dialogue a elle aussi besoin de CGenerique car elle aussi a un membre de ce type.

donc il me semble logique de devoir faire un header sous cette forme :


//Header Tool.h

Code :

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

1
2
3
4
5
6
7
8
9
 
#include "generique.h
 
Classe CTool
{
public:
 
   CGenerique m_generique;
}

quand a ma dlg, faire un header sous cette forme :

Code :

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

1
2
3
4
5
6
7
8
9
 
#include "Tool.h"
 
Class MaDlg public CDialog
{
public : 
   CTool m_tool;
   CGenerique m_generique;
}

evidement comme ca , ca ne compile pas, et j'ai beau deplacer mes includes, y a rien a faire, par pitié , a l'aide !!!!

PS : je suis toujours et encore plus, prenneur pour un cours particulier sur les includes, chez vous, ou chez moi dans les hauts de seine.

[farscape]

salut ,
il n'y a pas besoin de cours sur les includes ,il faut appliquer des regles:
voir faq:
http://c.developpez.com/faq/vc/?page=IDE#PbWithHeaders
les directives de gardes sont necessaires pour eviter les redéfinitions.

autre régle:
s'assurer qu'un en-tête est compilable de maniere autonome ,il doit inclure tout les en-têtes dont son contenu a besoin.

[giova_fr]

Merci pour ton info, je vais m'assurer que je puisse compiler chaque couple .h .cpp independamment