Salut,
 
J'ai un fichier toto.h que j'inclus avec un #include dans un autre fichier.
Dans toto.h y'a un #include "toto2.h", dans toto2.h y'a un #include "toto3.h" et dans toto3.h y'a un #include "toto.h".
 
D'où un probleme de bouclage a la compilation. Dans chaque fichier où ils sont inclus les .h sont indispensable car ce sont des déclarations de classes qui on un membre de type totoi: la classe toto a un membre de type toto2, la classe toto2 a un membre de type toto3 et la classe toto3 a un membre de type toto. Et c'est meme plus compliqué que ca parce que a terme certains toto auront plusieurs toto différents comme membres.

A priori il faut revoir ta conception;
ce genre de problème est inhérent à une mauvaise conception d'ensemble.

Tu peux te protéger de ca, a grand coups de gardes internes:
 
#ifndef _TOTO_1_H_
#define _TOTO_1_H_
 
...
 
#endif // _TOTO_1_H_
 
c'est même obligatoire des que ton projet commence a grossir, alors autant le mettre tout de suite.

 
 
et on met quoi comme code a la place des "..." ?
 
et que signie tous les _ et les majuscules pour remplacer _TOTO_1_H_ ?

 
 
ben je sais pas j'avais pourtant fait attention a faire quelquechose de bien propre, j'avais réfléchis avant de coder. Mais quand tu fais une classe, qu'est ce qui t'empeche de l'utiliser comme attribut dans n'importe quelle autre ? en quoi c'est une mauvaise conception ?

http://www.fredosaurus.com/notes-c [...] ifdef.html
ou alors
http://www.velocityreviews.com/for [...] oblem.html

#pragma once

amis de la compatibilite ...

bin écoutes, j'ai tellement mis de #ifndef pendant un moment, qu'au jour où j'ai rencontré le #pragma once j'ai trouvé ça élégant comme manière de faire.
 
alors qu'une directive spécifique (c'est ce qu'annonce un pragma) ne soit pas normalisée, je veux bien, mais ils aurait pu être un peu ouvert d'esprit avec un par exemple #include once ou j'en sais rien....
 
je trouve ça con d'avoir déjà à balayer tout le header là où le compilo pourrait s'arrêter à la première ligne (et un bricolage de derrière les fagots pour gérer le cas particulier, même si c'est mieux que rien)

 
Prédéfinit tes classes dans le .h et fait l'inclusion dans le .cpp ca évite des inclusion récursive de ce type... si j'ai bien tout compris à ton probleme.
 
dans toto.h

 
dans toto1.h

 
dans toto1.cpp

Oui je comprends que ca te broute (moi aussi   ), mais imagine qu'un gars doive passer derrière toi pour changer tes #pragma en #ifndef pour migrer vers g++ par exemple... Ca va le brouter encore plus. Le mieux c'est (selon moi) de faire un petit script qui génère direct un template de fichier header et d'implémentation (avec la licence d'exploitation et tout...).

g++ le supporte non ? (je crois avoir vu, quitte à émettre un deprecated ?)

Un poil plus d'infos (juste pour référence):
   http://gcc.gnu.org/onlinedocs/gcc- [...] .html#SEC8
 
Par contre, cimourdain a un problème de conception. Ce qu'il nous dit est:
J'ai une barrique, qui contient un jerrican, qui contient une grosse bouteille, qui contient une barrique (qui donc contient un jerrican, qui contient ... etc.) Ca cycle, et c'est ça le problème.  

#pragma once != include guard.
 
ce pragma ne sert qu'à dire à cl.exe de ne pas réouvrir et re-preprocesser un .h.  
 
include guard beats pragma everyday.

bah l'include gard, laisse ouvrir et processer du vide.....

merci

"référence circulaire"

mon programme n'est pas mal concu, on peut pas faire autrement.

Tu crois être le premier à te taper une référence circulaire ?

On NE PEUT PAS faire autrement on te dit. Il faut inventer un nouveau langage, ou modifier l'implémentation, mais il DOIT avoir une référence circulaire dans son modèle. Sinon, y aurait bien les pointeurs et les "forward class declaration", mais j'ai comme l'idée que ça ne résoud pas son problème...

Ah non, pas modifier l'implémentation, ca casserait tout ce qui ne marche pas.

la méthode de papangue fonctionne dans mon cas. Mais je comprends pas exactement tous les mécanismes qui sont en jeu... Si tu a l'explication papangue je suis preneur, histoire de pas faire des choses sans rien comprendre...

 
Le probleme ets qu'il y a des situations ou ils ne sont pas équivalent.
La bonne oslution serait d'avoir les deux.    

En fait tout compilateur decent detecte les include guards et ne rouvre pas le fichier.
Au pire le preprocesseur, c'est pas le truc le plus compliqué du monde.
 
En plus Herb Sutter le dit: chapitre 24
http://www.amazon.fr/Standards-pro [...] 2744071447
 
edit: g++ -> warning: #pragma once is obsolete

Bah tu prédéfinis ta classe, sans préciser quoi que ce soit, comme ça le précompilateur à une référence (même vide) à ta classe. Tu ne la définis qu'ensuite...

 
là je suis entièrement d'accord  

 
oui mais c'est bien, mais je trouve ça vilain.
 
un marqueur d'ouverture unique compact et explicite parfaitement lisible, propre, clair, c'est mieux.
 
le gros #ifndef/#define/#endif est lourd visuellement, c'est une implémentation possible (étalée dans tout le fichier) d'un fonctionnalitée, ça rajoute des lignes au sources qui peut déjà être bloated de trucs, et bonjour pour ne pas avoir de collisions de noms au #ifndef/#define (genre #define __FOO__ haha)
 
enfin c'est pas dramatique non plus... (c'est juste que le C++ c'est pas du cobol, donc rester sur une pratique historique bof je trouve ça vilain)