class chunk
{
child *list;
};
class child
{
parent *chunk;
};
Making two classes share each other?
Author
Hi there! :D
Let me try to explain what I want to do:
I have a number of terrain chunks, which each should keep a list of pointers to its children...
Each object (i.e a child) should also have a pointer to its parent (the terrain chunk).
Is there a way to do what I want?
Basically it's for collision detection and such, since only the children in the current object's terrain-chunk needs to be checked etc.
please don't comment on how I set up my class, since this is not the way I do it.. ;) It's just to give a more graphic view of what I want to do! :D
Thanks for your time,
Cheers!
You are describing a typical tree data structure. A node in a very simple tree might look like this:
struct Node { std::vector< Node * > children; Node * parent; Data nodeData; };
Are you asking about how to resolve the circular dependency? If so, you can forward declare classes...
class child;
class chunk
{
child *list;
};
-------------------------------------------------
class chunk;
class child
{
chunk *parent;
};
[Edited by - smitty1276 on March 7, 2006 2:28:00 PM]
class child;
class chunk
{
child *list;
};
-------------------------------------------------
class chunk;
class child
{
chunk *parent;
};
[Edited by - smitty1276 on March 7, 2006 2:28:00 PM]
Quote:Original post by smitty1276#include "Chunk.cpp"class child;class chunk{ child *list;};-------------------------------------------------#include "Child.cpp"class chunk;class child{ chunk *parent;};
Ummmm.... Did you just include your .cpp files in your .h file? I'm assuming that was a mistake. Just want to make sure that Rasmadrak doesn't try to do that in his project :-)
Author
Thanks! :D
What smitty suggested was spot on! This will help me QUITE a bit!! hehe, I've always "cheated" around this problem before, but this time I dont want to compromise :D
this way I can discard huge search lists and only search objects that are close to the current object, and even skip large frustum checks if the area objects are in isn't visible :)
Gaah.. thanks a million!
Cheers!
What smitty suggested was spot on! This will help me QUITE a bit!! hehe, I've always "cheated" around this problem before, but this time I dont want to compromise :D
this way I can discard huge search lists and only search objects that are close to the current object, and even skip large frustum checks if the area objects are in isn't visible :)
Gaah.. thanks a million!
Cheers!
Well, Ras...
For what it's worth, some would say that circular dependencies are a way of cheating as well, since good OO design would eliminate the need to do such a thing. We've all done it though. [wink]
For what it's worth, some would say that circular dependencies are a way of cheating as well, since good OO design would eliminate the need to do such a thing. We've all done it though. [wink]
Quote:Original post by smitty1276
Well, Ras...
For what it's worth, some would say that circular dependencies are a way of cheating as well, since good OO design would eliminate the need to do such a thing. We've all done it though. [wink]
Quite true - circular dependencies tends to increase class coupling and unwanted dependencies and to decrease reusability. For example, in you case, you won't be able to use your "chunk" class without including the "child" class too, even if you don't need it. One way to eradicate this nasty circular dependency is to introduce a "collidable" class from which both chunk and child will inherit (since they are, if I understood correctly, collidable objects).
HTH,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
