On Thu, 2007-12-27 at 15:17 +0100, Tamas Marki wrote: > On 12/27/07, Michael Sullivan <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-12-26 at 21:03 -0700, Thomas Hruska wrote: > > > 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 > > > > > > He does have the #ifdef/#ifndef's in place. If there were a > recursive > > > problem, the compiler would have died there. > > > > > > Michael, try this: > > > > > > Remove the 'drawbattle.h' #include from 'battle.h'. Then, before > your > > > declaration of Battle, do: > > > > > > class DrawBattle; > > > > > > That tells the compiler that somewhere else is going to be a full > > > class > > > definition of DrawBattle. This is the usual approach to dealing > with > > > circular references. > > > > > > -- > > > Thomas Hruska > > > CubicleSoft President > > > Ph: 517-803-4197 > > > > > > *NEW* MyTaskFocus 1.1 > > > Get on task. Stay on task. > > > > > > http://www.CubicleSoft.com/MyTaskFocus/ > > > > OK. The definitions for both Battle and DrawBattle are in battle.h, > > with the above mentioned addition above the Battle class. My errors > are > > still the same: > > > > g++ `sdl-config --cflags` -I/usr/local/include/mysql++/ > > -I/usr/include/mysql -L/usr/local/lib -c battle.cpp > > drawbattle.h:10: error: expected `)' before '*' token > > drawbattle.h:32: error: ISO C++ forbids declaration of 'Battle' with > no > > type > > drawbattle.h:32: error: expected ';' before '*' token > > battle.h:30: error: redefinition of 'class DrawBattle' > > drawbattle.h:7: error: previous definition of 'class DrawBattle' > > battle.cpp: In member function 'bool Battle::initialize()': > > battle.cpp:30: error: no matching function for call to > > 'DrawBattle::DrawBattle(Battle* const)' > > drawbattle.h:9: note: candidates are: DrawBattle::DrawBattle() > > drawbattle.h:7: note: DrawBattle::DrawBattle(const > > DrawBattle&) > > make: *** [battle.o] Error 1 > > > > If you need me to repost my code, please ask... > > Ok, one last try, then I give up. > Tell me WHY do you need to have a BattleDrawer inside the Battle > class? Especially since you have a Battle pointer in the BattleDrawer > class. Do they really need to know about each other? What if you want > to have a Battle object without a drawer (for example you'd write a > text-only version of the game)? What if'd you have hundreds of Battle > objects, all of them will have a drawer? > Wouldn't it be more logical that a BattleDrawer (that lives on its > own) gets a Battle object, and just draws it? No need for Battle to do > anything with drawing, and this way one drawer can take care of > drawing any number of battles you like. > A good design is always has to be first. You can't just start coding > without some thinking about the pattern first, or else you'll just run > into problems like this, that wouldn't exist if you'd have a design > and a clear vision of what should go where. > Maybe you should read a book about design patterns, or look at someone > else's similar project's source code to see how it's layed out...? > > -- > Tamas Marki
The only reason DrawBattle exists is because Thomas said that the SDL stuff doesn't belong in Battle. At any given time, at most one Battle object will exist (one battle at a time) and that Battle object will call the shots for the battle. It needs the DrawBattle object to control the multimedia (for now that's just graphics), However, DrawBattle will need to have access to Battle's Ally array, which is why I am passing the 'this' Battle object to it. Battle contains a DrawBattle object because all the drawing will happen through that object.
