On Dec 26, 2007 8:52 PM, Michael Sullivan <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-12-26 at 19:35 +0100, Tamas Marki wrote:
> > On Dec 26, 2007 5:41 PM, Michael Sullivan <[EMAIL PROTECTED]>
> > wrote:
> > > On Wed, 2007-12-26 at 17:35 +0100, Tamas Marki wrote:
> > > > On 12/26/07, Michael Sullivan <[EMAIL PROTECTED]> wrote:
> > > > > In my project I have moved the majority of SDL code from the
> > Battle
> > > > > class to a new class called DrawBattle. I'm trying to build it,
> > but
> > > > > DrawBattle refuses to recognize my Battle class. I know that
> > this
> > > > isn't
> > > > > finished, but I prefer to debug and rebuild as I go. I have
> > pasted
> > > > the
> > > > > code for only the relevant classes:
> > > >
> > > > [snip code]
> > > >
> > > > I didn't really read through all your code, but it seems like that
> > you
> > > > are falling into the 'recursive includes' trap, meaning that
> > battle.h
> > > > includes drawbattle.h and vice versa. Just think about it for a
> > moment
> > > > what would you do if you were the preprocessor... Confused yet? :)
> > > > You might need to rethink that part a bit.
> > > > HTH
> > > >
> > > > --
> > > > Tamas Marki
> > >
> > > How else do you propose that I make my party array available to
> > > DrawBattle? drawbattle.h and battle.h are each included only once...
> >
> > Well, if the classes _really_ need to know each other (as opposed to
> > one knowing about the other but not vice versa), then one way to do it
> > is with pointers. You don't need a full class declaration to specify a
> > member that is a pointer to a given class.
> > Observe (simplified for readability purposes)...
> >
> > // file1.h
> >
> > class B;
> >
> > class A
> > {
> > B* bPointer;
> > };
> >
> > // file2.h
> >
> > #include "file1.h"
> > class B
> > {
> > A aObject;
> > };
> >
> > But when you use the bPointer in class A's member functions you'll
> > need to include file2.h, but that's why you write the implementation
> > in the .cpp file (and that's where you include file2.h) - thus
> > escaping the circular includes.
> >
> > Still I think it might be better to rethink your design to avoid this
> > kind of confusion.
> >
> > --
> > Tamas Marki
>
> So are you saying that I should put the contents of drawbattle.h in
> battle.h?
I'm not suggesting anything, since I haven't thoroughly ready your source code.
What I do see is that your logic is not clear. I'd just create a
painter object that can accept a Battle object as a parameter for a
Draw function. That way Battle would not have to contain a drawer.
--
Tamas Marki
