Discussion :

[panthere noire]

Hello

Bon sa fait un moment que j'entends des avis diffèrent sur la manière de placer les #include

que ce soit dans les header ou le reste.
perso je fait le header *hpp , puis *.cpp -->#include "*.hpp"
ensuite le *.cpp dans le main.cpp -->#include "*.cpp"
et sa roule.
certain vienne de me dire qu'il ne faut pas mettre un #include *.cpp dans le main
bref c est pas très très claire, sans compter que les histoires de lien j'y comprend rien.... si ce n'est le fait que s'il trouve pas la lib,ou fichier il faut le lui passer en paramètre.

je cherche de la doc a ce sujet mai j'ai rien de concluant et les bouquin que j'ai ne parle pas de ce genre de sujet ... ou très peux

si quelqu'un a un tuto (en fr) ou de la doc je suis preneur.
merci d'avance

[Lucien63]

-On ne fait jamais d'include de cpp
-les fichiers cpp sont déstiné au définition (de classe, de fonctions ...)
-les déclarations (de classe, de fonctions ...) doivent être dans un fichier entête .h ou .hpp.
-si tu veux utilisé les fonctions ou autres de ton cpp, c'est le fichier entête (.h) qui lui est associé que tu doit inclure.
- par contre le fichier objet .obj ou .o ... issu de la compilation du cpp devra etre liée à ton executable. Si tu travail avec un EDI, le cpp devra faire partie de ton projet.

[panthere noire]

bon certe mai comment je fait pour que sa compile. par exemple:
main.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
 
#include <iostream>
#include "c_vector.cpp"
int main()//(int argc, char *argv[])
{
	//c_vector V;
	const int MaxV = 40;
	int i = 1;
	c_vector *Panier[MaxV];
 
	Panier[i] = new c_vector[i];
	std::cout << Panier[i]->m_get_nbr_vector() << std::endl;
	 delete [] Panier[i];
    return 0;
}

dans le c_vector.hpp

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
 
#ifndef DEF_ME_VECTOR
#define DEF_ME_VECTOR
#include <string>
#include <iostream>
 
class c_vector {
public:
	c_vector();	
	~c_vector();
	int m_get_nbr_vector();
	private:
	static int NbrVector;
 
};
int c_vector::NbrVector = 0;
#endif

dans le c_vector.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#include "c_vector.hpp"
 
c_vector::c_vector() { NbrVector++; }
c_vector::~c_vector(){ NbrVector--; }
 
int c_vector::m_get_nbr_vector() 
{
	return NbrVector;
}

(code compilable)
sa deviendrai quoi?

[burndev]

bonjour,

-On ne fait jamais d'include de cpp
-les fichiers cpp sont déstiné au définition (de classe, de fonctions ...)
-les déclarations (de classe, de fonctions ...) doivent être dans un fichier entête .h ou .hpp.
-si tu veux utilisé les fonctions ou autres de ton cpp, c'est le fichier entête (.h) qui lui est associé que tu doit inclure.
- par contre le fichier objet .obj ou .o ... issu de la compilation du cpp devra etre liée à ton executable. Si tu travail avec un EDI, le cpp devra faire partie de ton projet.

je pense que son explication est claire.

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
 
#include <iostream>
#include "c_vector.hpp"
 
int main()//(int argc, char *argv[])
{
	//c_vector V;
	const int MaxV = 40;
	int i = 1;
	c_vector *Panier[MaxV];
 
	Panier[i] = new c_vector[i];
	std::cout << Panier[i]->m_get_nbr_vector() << std::endl;
	 delete [] Panier[i];
    return 0;
}

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
 
#ifndef DEF_ME_VECTOR
#define DEF_ME_VECTOR
 
class c_vector {
public:
	c_vector();	
	~c_vector();
	int m_get_nbr_vector()const;
	private:
	static int NbrVector;
 
};
int c_vector::NbrVector = 0;
#endif

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#include "c_vector.hpp"
 
c_vector::c_vector() { NbrVector++; }
c_vector::~c_vector(){ NbrVector--; }
 
int c_vector::m_get_nbr_vector()const 
{
	return NbrVector;
}

le code que tu présente ne peut compiler

bon courage!

[Lucien63]

Bon,

Code :

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

int c_vector::NbrVector = 0;

Cette ligne, c'est quoi pour toi, une déclaration ou une définition ?








Une définition !

Et ça ce met où une définition ?










Dans le cpp !

[koala01]

Salut,

Peut être faudrait-il te rappeler la manière de travailler des compilateurs C++, cela te permettrait sans doute de comprendre comment tu dois t'y prendre et la raison qui fait que.

Il faut déjà comprendre que le compilateur va travailler, essentiellement, sur les fichiers d'implémentation (les fichiers portant l'extension *.cpp ou similaire) en les parcourant, comme toi, de haut en bas.

De plus, il faut savoir qu'il "oublient" systématiquement tout ce qu'il peuvent avoir fait lors du traitement d'un fichier d'implémentation au moment de passer à un fichier différent.

Enfin, il faut savoir qu'il ne connaissent, à tout instant, que ce qu'ils ont déjà rencontré: Lorsqu'il sont occupés à analyser la ligne 10 d'un fichier d'implémentation, les compilateurs ne connaissent de ce fichier que... les 9 premières lignes, un peu à l'instar de toi qui ne connait que les 9 premières pages d'un livre lorsque tu arrive au début de la dixième: tu sais ce qui s'est passé pendant les pages que tu as déjà lues, tu connais les intervenants que tu y a déjà rencontrés, mais tu n'as aucune idée des autres personnages que tu pourra rencontrer ni de ce qui pourra arriver dans les pages suivantes.

Si ils rencontrent l'utilisation dont ils ignorent encore tout, les compilateurs arrêteront de travailler en affichant une erreur.

Il faut comprendre ensuite que le processus de compilation d'une application se fait en trois passes:

1. le passage du préprocesseur qui va appliquer un certain nombre de macro sur le fichier, de manière récursive
2. la compilation "proprement dite", qui va générer un fichier contenant le "code binaire exécutable" (comprend: la suite d'instructions compréhensible par le processur) correspondant au fichier d'implémentation
3. l'édition des liens qui va regrouper l'ensemble des fichiers objets générés en un seul fichier, que le système considérera comme exécutable, et qui veillera à ce que chaque utilisation des différents "symboles" face référence à l'endroit dans ce fichier dans lequel le symbole est défini.

Les deux premières passes s'effectuent sur chaque fichier d'implémentation au moment de son traitement, alors que la dernière s'effectue sur l'ensemble des fichiers objets obtenus lors des deux premières.

Ainsi, lorsque tu va compiler un fichier *.cpp, le préprocesseur va passer et, chaque fois qu'il va rencontrer, par exemple, une directive #include, il va la remplacer par... le contenu du fichier indiqué.

S'il rencontre une directive #define, il va créer un "symbole" du nom correspondant et lui affecter la valeur indiquée, et s'il rencontre une directive #ifndef ou similaire, il "gardera" ce qui se trouve entre la directive et la directive #endif correspondante en fonction du résultat de l'évaluation de l'expression qui lui est donnée.

Puis le compilateur "proprement dit" prendra le relais et convertira les différentes instructions "humainement lisibles" en instructions compréhensibles par le processeur.

Lorsqu'il rencontre des définitions de fonctions, de variables ou de types, il va créer des "symboles" permettant d'identifier ces fonctions, variables ou types de manière "unique et non ambigüe", qui seront accessibles, selon le cas, dans un blocs d'instruction donné (c'est le cas des variables définies dans les fonctions), dans un fichier objet (c'est le cas des variables définies de manière globale) ou carrément dans l'ensemble du projet (c'est le cas des définitions de fonction et de type).

Le fait est que le choix du noms que le compilateur donne aux différents symboles suit une logique stricte et clairement définie, ce qui fait que, le nom d'un symbole particulier (par exemple celui correspondant à une fonction particulière) sera identique quel que soit le fichier d'implémentation ou l'endroit auquel il apparait dans un fichier d'implémentation.

Comme l'éditeur de liens se basera sur ces différents symboles pour mettre en relations les appels (de fonctions) et les accès (de variables) en relation avec l'endroit où les symboles sont définis, il faut vraiment que ces symboles permettent d'identifier les choses de manière unique et non ambigüe.

En effet, si l'éditeur de liens n'arrive pas à identifier clairement l'endroit où se situe la définition d'un symbole, il ne sera pas en mesure de mettre les différents appels ou accès à ce symbole avec l'endroit où le symbole est défini, et il te jettera comme un malpropre.

Ce phénomène tout à fait logique est connu sous le nom de la "règle de la définition unique" (One Definition Rule, abréviée en ODR, en anglais).

L'idée est donc de séparer ce qui permet simplement au compilateur de savoir que quelque chose existe (les "déclarations") en les plaçant dans un type de fichier appelé "fichier d'en-tête" (header, en anglais), généralement affublé de l'extension *.hpp que l'on pourra inclure dans tout fichier dans lequel le compilateur a besoin de savoir que cela existe, de ce qui permet au compilateur de le définir (l'implémentation ou la définition) qui sera placé dans un type de fichier appelé "fichier d'implémentation", généralement affublé de l'extension *.cpp.

Le seul type de fichier que l'on inclura sera donc le type de fichier "d'en-tête", car il contient tout ce qui est nécessaire au compilateur pour savoir que "quelque chose existe".

Il est possible, si l'on a besoin de quelque chose qui est déclaré dans un autre fichier d'en-tête pour déclarer une chose supplémentaire, d'inclure un fichier d'en-tête à l'intérieur d'un autre (c'est pour cela que le préprocesseur travaille de manière récursive ), il est, bien sur, possible d'inclure un fichier d'en-tête dans un fichier d'implémentation, de manière à permettre au compilateur de savoir que le contenu du fichier d'en-tête existe, mais il est interdit d'inclure un fichier d'implémentation ou que ce soit au risque que le compilateur définisse plusieurs fois les symboles correspondant à ce qui est défini dans ce fichier, avec la conséquence que j'ai expliquée plus haut au niveau de l'éditeur de liens.

Evidemment, ces explications ne sont pas tout à fait justes parce que pas tout à fait complètes, et il existe un certain nombre d'exception (la définition des fonctions inline et tout ce qui touche aux template), mais en parler m'aurait obligé à écrire une intervention encore plus longue et n'aurait sans doute pas facilité la compréhension.

En conclusion, on peut dire que l'on n'inclut jamais un fichier *.cpp et que tout ce que l'on peut inclure (n'importe où ), c'est des fichier *.hpp (ou d'extension équivalente)

[panthere noire]

Merci a koala01 en particulier qui m'a enfin expliquer plus clairement le cheminement de la compilation
mai aussi les autres

je doit dire que les livre parle bien du processeur mai ne rentre pas dans les détail et forcément sa coince par la suite....

je vai donc méditer un peux sur les nouvelles informations
Lucien63:

ben tu vois c'est pas si évident sauf quand on connaît le principe

burndev:

j'utilise geany, je passe par la console,et si sa compile
mai regarde la différence en le code que j'ai donner et le tien tu verra qu'il te manque quelque ligne surement du a un écran plus petit et du copier coller trop court

[panthere noire]

j'ai encore une petite question qui concerne toujours les includes.

le c++ permet de ré-utiliser les fichier qui comprenne les classe dans différent projet.
donc ceux-ci ce retrouve assez facilement avec :

#include <iostream>
#include <string>

donc j'imagine que cela ne devrai être mis qu'une seul fois ?
parce que modifier chaque *.h jute pour supprimer les include (ou les rajouter)
peux vite devenir pénible.

Merci d'avance

[koala01]

Attention, les fichiers dont tu parles font malgré tout partie des fonctionnalités fournies par le standard, ce qui justifie sans doute en grande partie que ces fichiers là en particuliers se retrouve dans une très grande majorité de projets

Ceci dit, il n'y a rien à faire: si tu as besoin du contenu d'un fichier d'en-tête, tu es obligé de l'inclure, que ce soit de manière directe (directement à l'aide de la macro #include <fichier requis> ) ou de manière indirecte (parce que tu inclut un fichier qui inclut le fichier qui inclut le fichier requis).

Par contre, tu peux parfaitement envisager d'inclure un fichier qui n'est pas absolument nécessaire, bien que cela risque d'augmenter le temps de compilation.

Tu peux donc parfaitement envisager de regrouper dans un fichier "à toi" l'ensemble des fichiers issus de projets externes dont tu risque d'avoir besoin pour ton projet particulier en veillant à l'inclure (toujours de manière directe ou indirecte ) dans l'ensemble de fichiers de ton projet.

Tu aurais cependant, pour éviter de trop augmenter le temps de compilation, à envisager de recourir à ce que l'on appelle "les en-têtes précompilées" (PCH pou PreCompiled Headers).

L'idée de ce principe est *relativement* simple:

Si tu inclue de manière systématique les même fichiers dans le même ordre, et que ces fichiers ne sont pas modifiés le résultat obtenu sera toujours identique.

On peut donc se dire que, si on arrive à garder le résultat généré lors de la première fois où l'on gère ces inclusions, on peut le récupérer par la suite à chaque fois que ces fichiers "regroupés" seront requis et donc gagner le temps nécessaire à leur gestion, qui sera, tu t'en doute, proportionnel au nombre de fois où ces fichiers sont inclus dans d'autres.

Sur des projets moyens à (très) gros, le gain de temps peut s'avérer être particulièrement intéressant

Mais, cet avantage ne fonctionnera qu'à partir du moment où l'on aura l'assurance que les fichiers que l'on inclue ne seront que rarement modifiés, parce que toute modification de ceux-ci nous obligerait à les gérer à nouveau.

Tu comprendra donc que ce sera particulièrement efficace avec les fichiers d'ent-êtes issus de projets externes (vu que tu les modifies vraiment très rarement ) mais que l'efficacité du système au niveau de ton projet dépendra grandement de la stabilité des fichiers que tu essaye de gérer sous la forme d'en-têtes précompilés

EDIT: si tu comprend l'anglais, tu peux passer sur cette page qui explique l'utilisation des en-têtes pré compilées sous Gcc

[panthere noire]

Merci pour ta réponse ,bon en gros si je comprend bien sa ne dérange pas que sa soie plusieurs fois inclus ?

pour le précompiled c'est peut être encore trop tôt pour le gros débutant que je suis , mai sa peux servir a d'autre gens

il va falloir que j'envisage de prendre des cours d'anglais
Merci encore pour ta réponse 8je dormirai moins c.. ce soir

[koala01]

Merci pour ta réponse ,bon en gros si je comprend bien sa ne dérange pas que sa soie plusieurs fois inclus ?

Il peut y avoir un problème s'il est inclus plusieurs fois (souvent de manière indirecte) dans un seul et même fichier.

C'est pour cela que l'on met des "guard dogs" (des "chiens de gardes" que l'on appelle "garde anti inclusions multiple") sous la forme de

Code :

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

1
2
3
4
5
#ifndef NOM_DU_FICHIER_HPP
#define NOM_DU_FICHIER_HPP
/* le contenu du fichier */
 
#endif

Cette simple précaution aura pour résultat de faire en sorte que le contenu du fichier ne se retrouve qu'une seule et unique fois dans le fichier d'implémentation, même si le fichier en question est inclus de nombreuses fois de manière indirecte.


Pour ce qui est d'avoir un fichier inclus dans plusieurs "unités de compilation" (comprend: un fichier d'implémentation + l'ensemble des fichiers d'en-tête dont il dépend, de manière directe et indirecte), cela ne pose aucun problème, hormis un éventuel surplus de temps lors de la compilation

pour le précompiled c'est peut être encore trop tôt pour le gros débutant que je suis , mai sa peux servir a d'autre gens

Mais, comme tu en auras déjà entendu parler, tu pourra t'y intéresser "en temps utiles": tu ne restera pas un "gros débutant" éternellement

il va falloir que j'envisage de prendre des cours d'anglais

Ca, c'est indispensable dés le moment où tu envisage de t'intéresser au développement (comme dans d'autres domaines, d'ailleurs): L'anglais est littéralement la langue véhiculaire dés le moment où l'on "internationalise" la connaissance