Cross dependant classes

Should I make a handler class or something? Since the compiler hates this cross dependancy, but I would like both classes to be able to handle the collision detection.

Code:

#ifndef C_RECT_H
#define C_RECT_H

#include "C_Circ.h"

class C_Rect
{
    public:
         C_Rect();
         C_Rect(int X,int Y,int SX,int SY);
    void Set_Attribs(int X,int Y,int SX,int SY);
    bool Collision_Test(C_Circ);
    bool Collision_Test(C_Rect);

    int  Get_X();
    int  Get_Y();
    int  Get_SX();
    int  Get_SY();

    private:
    int x;
    int y;
    int sx;
    int sy;

};

#endif // C_RECT_H

Code:

#ifndef C_CIRC_H
#define C_CIRC_H

#include "C_Rect.h"

class C_Circ
{
    public:

         C_Circ();
         C_Circ(int X,int Y,int R);
    void Set_Attribs(int X,int Y,int R);
    bool Collision_Test(C_Circ);
    bool Collision_Test(C_Rect);

    int  Get_X();
    int  Get_Y();
    int  Get_R();

    private:
    int x;
    int y;
    int rad;

};

#endif // C_CIRC_H_INCLUDED

Perhaps having an actual base class that handles stuff as collisions would be a good idea?

In such situations you'd generally use forward declarations. Instead of including the whole header, put

Code:

class C_Circ;
class C_Rect;

That doesn't feel like it's a good idea. It will introduce class dependencies, and thinking about it, why should a Circle know about a Rect and vice versa?

The context is one of two shapes deciding if they intersect.

Look up inheritance and maybe even polymorphism.

Inheritance is when you set it so that one or more classes derive from another.
Polymorphism is some way to use the more generic class to control some behaviour of the more specific classes.

Suppose:

Code:

class Shape { };
class Square : public Shape { };
class Circle : public Shape { };

std::vector<Shape*> shape_list;
std::vector<Shape*>::iterator it;

for(it = shape_list.begin(); it != shape_list.end(); it++) {
    // do stuff with this shape
    Shape* p = NULL;
    if((p = dynamic_cast<Circle*>(*it)) != NULL) { }
    if((p = dynamic_cast<Square*>(*it)) != NULL) { }
}

I'm just not certain it really is dynamic_cast that is to be used in this case. I haven't used those kind of casts in a long time (dynamic/static/reinterpret/const_cast<>).

dynamic_cast should not be used here. dynamic_cast is used to "upcast" classes, that is, case the type from a base class to a derived class. But that will not solve the problem.
Having to classes "know" each other is bad idea. Not only will it introduce dependencies on all the other objects, which will cause a recompile of all classes if you modify one, but it will also force you to implement N² functions where N is the number of shapes.
For each shape you add, you have to add a new function to test against this new shape in the existing classes and add functions in the new class. If you count, that will add up to N².

One idea is to create some kind of collision manager. But this brings up the exact same problem. You have to implement N² functions to test collisions.
This is exactly why polymorphism was invented. You can create one function that will test collision between two shape objects. This means you should have a common base class for collision (and probably other things, as well).
The base class could either contain a virtual method for getting collision data, or store some kind of collision data in the base class. The later is probably cheaper, but may take more memory.
But if you implement this, then it seems pointless to have a collision manager since the base class could implement the collision testing.

Originally Posted by ~Kyo~

Should I make a handler class or something? Since the compiler hates this cross dependancy, but I would like both classes to be able to handle the collision detection.

Code:

#ifndef C_RECT_H
#define C_RECT_H

#include "C_Circ.h"

class C_Rect
{
};

#endif // C_RECT_H

Code:

#ifndef C_CIRC_H
#define C_CIRC_H

#include "C_Rect.h"

class C_Circ
{
};

#endif // C_CIRC_H_INCLUDED

If you have a dependency like this:

class A <--> class B

just use your nomal "includes" at the beginning with appropriate precompiler "ifndefs" like you showed it before and take care of the linker.

The linker just adds new stuff that is already needed by previous parts of the code. which means you have to link your code after compiling like this:

linker classA.o classB.o classA.o

If you want to compile a single file without linking it (for example in a makefile) just use the "-c" option of your compiler. the compiler just checks for appropriate declarations in the "#include" files and everything works out.



Axl

Originally Posted by Axl

If you have a dependency like this:

class A <--> class B

just use your nomal "includes" at the beginning with appropriate precompiler "ifndefs" like you showed it before and take care of the linker.

Generally, that circular inclusion will not work, and if it does work, it is because one of the header inclusions was not necessary in the first place.

Take ~Kyo~'s example: suppose we compile a translation unit that includes C_Rect.h. Now, C_Rect.h includes C_Circ.h which includes C_Rect.h. The second include of C_Rect.h effectively does not happen due to the header inclusion guards. Well and good. However, C_Circ.h still needs the declarations and definitions from C_Rect.h. Since C_Rect.h was not included, there would be compile errors, so we never get to take care of the linker. But if C_Circ.h does not need any declaration or definition from C_Rect.h, there would not be a problem... but then we would not have needed to include C_Rect.h in C_Circ.h to begin with.