Salut à tous,
 
Je me pose une question un peu bête.
Je fais du C++ depuis des années, et j'ai toujours pris soin d'éviter d'inclure des .h dans d'autres .h. Quand on utilise des pointeurs, c'est OK, il suffit de faire :
 

 
Ensuite, on inclue Toto.h dans Tata.cpp, et ca roule. Mais si je veux éviter un pointeur, existe-t-il une solution sans inclure le .h ? Exemple :
 

 
Voilà, merci
 
Edit : Je cherche à rendre certains choses plus clean dans mes projets. Je suis même pas certain que ce soit possible de faire ca sans #include, mais je demande quand même

Je ne comprends pas ton problème. POURQUOI tu veux éviter de mettre des .h dans des .h? A mon avis c'est la bonne solution, en prenant soin de mettre des include-guards (#ifndef HEADER #define HEADER ... #endif ou #pragma once).

Pareil, j'ai pas trop compris le problème. Effectivement, pour pas avoir des problématique de multi-include du même .h, il faut protéger avec les #ifndef et autres joyeusetés (pb qu'on a souvent pas dans d'autres langages au passage).
En PHP, tu fais un include_once() ou require_once() et t'es tranquille.

Et bien j'avoue que je ne sais pas trop... Ça fait partie des règles de mon taf. Enfin plutôt bonnes pratiques. C'est une histoire d'optimisation de ce que j'ai compris, et depuis j'ai toujours limité, en utilisant des pointeurs, des New et de delete.

Donc en soit, ça ne sert à rien de s'en priver au final ?

Faudrait demander à "Joel F" qui maîtrise bien le sujet.

Bonjour !
 
Pour avoir eu le problème sur un projet relativement conséquent, dans lequel il y avait beaucoup trop d'includes dans des .h, le problème est que la modification d'un fichier .h peut impliquer la recompilation de la moitié du projet, à cause des dépendances induites par ces inclusions, même si, au final, elles ne sont pas nécessaires.
 
J'avais, à l'époque, pris 2 jours pour nettoyer à peu près tous les includes "problématiques", c'est à dire ceux d'autres classes du projet, pas ceux d'un framework, par exemple (qui ne changent jamais), et le gain en recompilation du projet était vraiment appréciable lors de la modification de certaines classes assez centrales. Et je ne parle pas de gagner 10 secondes sur une minute
 
Après, il est régulièrement nécessaire d'inclure des .h dans d'autres .h, comme dans l'exemple donné (je pense que c'est dû à la taille de l'objet, que le compilateur a besoin de connaître pour pouvoir utiliser les bons décalages pour accéder aux différents attributs).

D'après le créateur du C++ il n'y a rien de pire que des new et des delete. Et certainement pas des headers inclus dans d'autres.
 
Une exception, en cas de dépendance circulaire, par exemple si Toto dépendait lui-même de Tata.
 
Enfin comme dit au-dessus, la bonne pratique est d'inclure dans un fichier (header ou non) seulement ce qui est nécessaire.
Par exemple dans bien des cas le header d'une classe n'a pas besoin d'inclure tout ce dont la classe dépend. Ces fichiers pourront être inclus dans le fichier source de la classe.

 
Si ta boite te demande de faire ça, faut changer de boite. Clairement ils pipent rien à ce qu'il font.

Ca s'appelle forward declaration.
C'est pratique pour éviter trop de dépendances entre fichiers.
 
Dans le premier exemple, si Toto.h change, Tata.h lui ne changera pas et n'impliquera pas la recompilation d'un éventuel Tata.cpp.
 
Dans ce cas là, "class Toto" est de type incomplet, ce qui est OK pour un pointeur.
 
Par contre, lorsque tu déclares une variable et non un pointeur, ton type doit être complet.
 
Plus d'info : https://stackoverflow.com/a/553869/857620, https://en.wikipedia.org/wiki/Forward_declaration.

Pour moi c'est une bonne pratique, on le fait chez nous.
La guideline Google le déconseille par contre.

 
Les GL Google sont fait pour google. Si les boites arretaient de penser qu'elles ont les pbs de Google, ca serait pas mal.
La seule chose que font le GLG, c'ets niveler par le bas

Après tu peux avoir plusieurs déclaration de classes dans un .h