[C++] - Problema direttiva #include

[unomichisiada]

Salve ho il seguente problema:ho una classe che chiamiamo CPippo che ha come variabile membro una lista di elementi di tipo CPluto,inoltre alcuni metodi di CPippo prendono come parametri delle variabili CPluto.
CPluto dal canto suo ha anch'essa dei metodi che prendono come argomenti delle variabili CPippo.Il problema è che il compilatore non riesce a gestire questo incrocio e mi da errori del tipo "classe CPluto non definita" nonostante in pippo.h ci sia #include "Pluto.h" e in pluto.h ci sia #include "Pippo.h".Momentaneamente ho risolto la cosa facendo estendere a CPippo un'interfaccia IPippo definita in pluto.h e mettendo come tipi di parametro nei metodi di CPluto non più dei CPippo ma degli IPippo,in questo modo non è più necessario mettere in pluto.h #include "Pippo.h" e mi basta mettere in pippo.h #include "Pluto.h" .
La soluzione però non mi garba tantissimo ,mi sembra veramente poco elegante, vorrei sapere se esiste qualche direttiva di preprocessore che mi può consentire di non usare questo sotterfugio.Il compilatore è quello del Visual Studio.net.
Grazie.

[anx721]

Hai per caso risolto il problema?

Deve esserci un modo per farlo...in java non darebbe nessun problema, ma c/c++ sono cosi capricciosi su queste cose...ma mi interessarebbe sapere come fare se c'è una classe A che fa riferimento ad una classe B che a sua volta fa riferiemnto ad A.

[unomichisiada]

Si ho risolto (anche se poi non mi è più servito perchè ho stravolto completamente il codice per fare in un'altro modo tutto quanto).In prartica basta mettere in Pippo.h,(all'inizio subito dopo le direttive di preprocessore)

class CPluto;

ed in Pluto.h (sempre all'inizio)

class CPippo;

(oltre ovviamente alle direttive di inclusione incrociate di cui ho parlato),tutto fila liscio così.
Mi scuso per essermi dimenticato di postare la soluzione,è sempre buona norma farlo (e in genere lo faccio)!

[Angioletto]

non vorrei sbagliare, ma non si poteva risolvere il tutto dichiarandole classi amiche?

[anx721]

Non penso, le classi amiche servono per consentire l'accesso a membri privati; qui il problema era che il compilatore trovava un riferimento ad una classe nonm dichiarata.

[unomichisiada]

Non penso, le classi amiche servono per consentire l'accesso a membri privati; qui il problema era che il compilatore trovava un riferimento ad una classe nonm dichiarata.

Infatti,bravo!No la soluzione è proprio quella che ho postato.Tra l'altro è la più corretta anche dal punto di vista dell'ingegneria del software perchè se pure dichiarare le due classi amiche funzionasse avrebbe l'effetto (magari indesiderato) di rendere possibile l'accesso ai membri privati rispettivi.