moi g toujours tout mis ds les includes et les define ds toto.hpp et ds toto.cpp je mets #include "toto.hpp".
mais est-ce vraiment comme ca qu'il fo faire?

Ben oui....
Mais tu fais comme tu veux.....

ca je me doute, mais qu'est est la "norme" pour les define et les includes?

Personnellement quand j'ai un projet dont le nom est toto par exe, dans tous les .cpp je met #include "toto.h"
et dans toto.h je met tous les includes necessaires au bon fonctionnement du prog.
 
Les def de struct aussi dans le h, et les defines ca depend.

tout ds un seul .h???
je parle en c++ la.

nan pas tout.
mais par exemple pour du C++.
Tu fais une classe NIMP, dans NIMP.cpp j'aurai un #include "nimp.h", et dans NIMP.h j'aurai  
#include <windows.h>
#include <stdlib.h>
 
etc...

ouais oki je suis d'accord moi je fais comme toi.
mais si tu as nimp.h et nim.cpp
et toto.cpp et toto.h
et que ds ton toto.h t'as un #include nimp.h,
c po sur que les includes de ton nimp.h soit necessaires a toto.
ceci pour dire que je me demande si ds les .h fo po mettre ce qui est visible par les autres .h, et mettre ds les .cpp uniquement les trucs necessaires a ton .cpp
 
je suis po sur d'etre clair mais bon

Ben en fait je pense que tu peux faire comme tu veux.
Normalement au debut de chaque .h t'as un #ifndef #define, comme ca si tu inclus deux fois le meme .h ca chie pas.

 
Tu n'as pas besoin de savoir ce qu'inclut nimp.h pour savoir ce qu'il faut inclure ou non dans toto.h.
Si par exemple nimp.h incluait titi.h et que toto.h avait aussi besoin de titi.h il faudrait quand même inclure titi.h dans toto.h pour être "propre". Dans le cas contraire, si un jour tu décidais que nimp.h n'incluais plus titi.h, ben alors ton toto.h il ne compile plus.
C'est un exemple tout simple mais avec des dizaines de fichiers à gérer mieux vaut "penser" chacun d'entre eux indépendamment car sinon c'est la galère pour trouver les dépendances indirectes.
Tu inclus bien des trucs genre stdio.h ou string.h sans savoir s'ils s'incluent entre eux, non? Ben c'est un peu comme ça qu'il faut voir les choses.
 

 
Si un .cpp a besoin d'un .hpp que le .hpp de ce .cpp n'a pas besoin, je mets l'include dans ce .cpp. C'est ce que tu pensais faire?
 

 
Mouais moi aussi.

[edtdd]--Message édité par Krueger--[/edtdd]

<<Si un .cpp a besoin d'un .hpp que le .hpp de ce .cpp n'a pas besoin, je mets l'include dans ce .cpp. C'est ce que tu pensais faire? >>
 
ouais c ca

tu fais comme tu veux tant que tu peux inclure ton .h autant de fois que tu veux avec:
#ifndef __MON_H__
#define __MON_H__
 
class Mon {
...
}
#endif

si tu veux etre clean
tu ne mets dans tes .h
que les infos que tu souhaites
partager => interface
et dans .cpp tout ce qui concerne
l'implantation.
 
exemple ton type maclasse est declare avec un membre
qui a besoin d'une declaration externe
 
contenu de maclasse.h:

 
deuxieme solution, tu ne desires pas
inclure cette declaration dans maclasse.h
en fait tu n'en n'as pas besoin si tu
declares var1 comme une reference vers un objet
de type "mon_type_externe".
 
deuxieme implantation de maclasse.h

dans ce cas, des que tu voudras utiliser les  
proprietes et methodes de mon_type_externe
il faudra penser a inclure au prealable "declaration1.h"
 
Si ton souci est la rapidite de compilation
ainsi que l'encapsulation, ne mets dans ton header
que ce qui concerne l'interface et deplace
la partie implantation dans le .cpp
(cela inclut les headers qui ne sont pas
utilises par la definition mais qui sont utiles
au code)
Evidemment il y a des cas ou il faut
faire autrement, notamment quand pour
des raisons d'efficacite, tu veux que les objets
puissent etre entierement locaux et que ses methodes
soient inlines.
(abstraction et performance s'opposent parfois)
 
A+
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]