Need help with declarations (simple question)

[twoeyedhuman1111]

Okay, I have this sample code:

class a;
class b;

class b
{
public:

private:
class a foo;
}

class a
{};

I get this compilation error saying that there's an error with the
forward declaration and that i'm doing an invalid use of an undefined
type. I'm not sure how to get the compiler to recognize that class a
will be defined later and it's okay if I use it as a type now.

So how do I get the compiler to let me declare variables with a class
that hasn't been defined yet?

[red floyd]

twoeyedhuman111 1 wrote:

Okay, I have this sample code:

class a;
class b;

class b
{
public:

private:
class a foo;
}

class a
{};

I get this compilation error saying that there's an error with the
forward declaration and that i'm doing an invalid use of an undefined
type. I'm not sure how to get the compiler to recognize that class a
will be defined later and it's okay if I use it as a type now.

So how do I get the compiler to let me declare variables with a class
that hasn't been defined yet?

You can't. You can declare variables of type *pointer to* a class that
hasn't been fully defined, and you can declare variables of type
*reference to* a class that hasn't been fully defined, but you can't
declare a plain variable of that type.

Also, in your declaration of b, you don't need the keyword "class" in
front of "a foo;"

[twoeyedhuman1111]

I guess I can't make a binary tree then.. Because I have two classes in
my binary tree:
xbasednode
ybasednode

I don't really need to explain exactly what they do, but they both use
each other in their source code, and in the same way in the above
example..

Perhaps with extern I could defeat my compiler...

Also, in your declaration of b, you don't need the keyword "class" in
front of "a foo;"

Yeah.. I didn't see that lol. Nice job seeing that.

[Artie Gold]

twoeyedhuman111 1 wrote:

I guess I can't make a binary tree then.. Because I have two classes in
my binary tree:
xbasednode
ybasednode

I don't really need to explain exactly what they do, but they both use
each other in their source code, and in the same way in the above
example..

Perhaps with extern I could defeat my compiler...

Also, in your declaration of b, you don't need the keyword "class" in
front of "a foo;"

Yeah.. I didn't see that lol. Nice job seeing that.

Let's think about how much sense that makes.

Suppose you *could* do what you (think) you want to, i.e. have two
classes, again call them A and B, where every B has an instance of A in
it and every A has an instance of B in it. Question: How big is an
instance of A?

*Pointers*, however, do not exhibit this problem; the compiler *knows*
how big the pointer to the instance of a class is.

Why don't you show some (closer) to real code to illustrate what you're
trying to do?

HTH,
--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com (new post 8/5)
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

[Kai-Uwe Bux]

twoeyedhuman111 1 wrote:

I guess I can't make a binary tree then.. Because I have two classes in
my binary tree:
xbasednode
ybasednode

I don't really need to explain exactly what they do, but they both use
each other in their source code, and in the same way in the above
example..

Perhaps with extern I could defeat my compiler...

Probably not. You seem to think that you are dealing with some arbitrary
restriction that somehow made it into the language definition. However,
there is a valid reason *why* two classes cannot mutually contain fields of
the other type: at some point the compiler has to determine the size of
objects of type xbasenode and of objects of type ybasenode. If xbasenode
objects have, among other data members, a field of type ybasenode, you get

sizeof(xbasenod e) > sizeof(ybasenod e)

and conversely from the other inclusion you get

sizeof(ybasenod e) > sizeof(xbasenod e)

This is a contradiction that cannot be resolved. Hence the restriction to
pointers: their size is not a problem.
Best

Kai-Uwe Bux

[twoeyedhuman1111]

Okay so I guess doing things the way I'm doing them is bad design and
makes the compiler sick. Perhaps I could combine both classes into
one... The only differences between xbasednode and ybasednode are the
way they handle their input.

The xbasednode and ybasednode store sprites and sort them by x and y
respectively.

ybasednode's code is so unreadable right now, that I can't even
understand it...

xbasednode's code: (beware, it's very long for readability)
class xbasednode
{
public:
xbasednode() {
haschildren = false;
};
~xbasednode();
// checks whether this is a right or left
// based child and tells parent it's dying;
void rChildIsBeingDe stroyed() {
rightnode = NULL;
};
void lChildIsBeingDe stroyed() {
leftnode = NULL;
};
void amNowRightNode( ) {
/* tells this node that it's a right node */
childside = RIGHTBASEDNODE;
};
void amNowLeftNode() {
/* tells this node that it's a left node */
childside = LEFTBASEDNODE;
};
ybasednode * GetRight() const {
if (rightnode != NULL) return rightnode;
/* else */
return NULL;
};
void SetRight(ybased node * daNode) {
rightnode = daNode;
rightnode->amNowRightNode ();
haschildren = true;
};
void MakeRight() {
rightnode = new ybasednode;
rightnode->amNowRightNode ();
/* tell its a right based node*/
haschildren = true;
};

ybasednode * GetLeft() {
if (leftnode != NULL) return leftnode;
/* else */
return NULL;
};
void SetLeft(ybasedn ode * daNode) {
leftnode = daNode;
leftnode->amNowLeftNode( );
haschildren = true;
};
void MakeLeft() {
leftnode = new ybasednode;
leftnode->amNowLeftNode( );
haschildren = true;
};
void SetParent(ybase dnode * parentToBe) {
parent = ParentToBe;
};
ybasednode * GetParent() {
return parent;
};
// void addToList(sprit e * x) { itsdata.push_ba ck(x); /*add a
new sprite*/};

// if we have children for these next 3
//, pass these parameters on to the children
// remove a sprite from list by id
void removeFromList( int id);
// remove a sprite from list by x,y
void removeFromList( int x, int y);
// remove sprites within a rectangle
void removeFromList( t3h::rect x);
void update();

void draw();

private:
int childside; // tells whether this is a right or left child
bool haschildren;
std::vector<spr ite*> itsdata;
ybasednode * parent; // the reason these are y
// based is so that x and y nodes
// repeat each other
ybasednode * rightnode;
ybasednode * leftnode;
t3h::rect itsarea;
};

//------------------------------------------------
void xbasednode::Dra w()
{
for (int a = 0; a != itsdata.size(); a++)
itsdata[a]->Draw();
}

// ------------------------------------------------
void xbasednode::Upd ate()
{
int temp_x1, temp_y1, temp_x2, temp_y2,
temp_x3, temp_y3, temp_x4, temp_y4; // for collision detection int

sizeoflist = itsdata.size(); // check collision with all
//other sprites except itself

for (int a = 0; a != sizeoflist; a++)
{
itsdata[a]->Update();

// test a collision with every other sprite
for (int j = a+1; j < sizeoflist; j++)
{
// see my paper about how this works

temp_x1 = itslist[a]->GetX();

temp_y1 = itslist[a]->GetY();

temp_x2 = temp_x1 + itslist[a]->GetWidth();

temp_y2 = temp_y1 + itslist[a]->GetHeight();
// just to make sure we don't go over our list
if (a+1 != itslist.size()+ 1)
{
temp_x3 = itslist[a+1]->GetX();

temp_y3 = itslist[a+1]->GetY();

temp_x4 = temp_x3 + itslist[a+1]->GetWidth();

temp_y4 = temp_y3 + itslist[a+1]->GetHeight();
}

if ((temp_x4 > temp_x1 > temp_x3
&& temp_y3 < temp_y1 < temp_y4) ||
(temp_x4 > temp_x2 > temp_x3 && temp_y3 < temp_y1 < temp_y4) ||
(temp_x4 > temp_x1 > temp_x3 && temp_y3 < temp_y2 < temp_y4) ||
(temp_x4 > temp_x2 > temp_x3 && temp_y3 < temp_y2 < temp_y4))

// if one of sprites points is inside one of the other sprites
// points, then a collision has been detected

itslist[a]->CheckCollision (itslist[a+1]);

// so lets tell the sprites that then, shall we?
}
}
// if we've exceeded our size limit, then
// lets pass our sprites onto the children
if (sizeoflist > MAXIMUMLISTSIZE )

{

// of course, for safety reasons, don't
//create more children when we have them, lol
if (haschildren == false)
{
rightnode = new ybasednode;

rightnode->amNowRightNode (); /* tell its a right based node*/

leftnode = new ybasednode;

leftnode->amNowLeftNode( ); /* tell its a left based node*/

// now that we've had sex and had children,
//lets sort out our sprites and give them to our children
//just like a will

for (int a = 0; a < sizeoflist; a++)
{

//if (itsdata[a].GetY() <

}

}

}

} // end of update function

[Ian]

twoeyedhuman111 1 wrote:

I guess I can't make a binary tree then.. Because I have two classes in
my binary tree:
xbasednode
ybasednode

I don't really need to explain exactly what they do, but they both use
each other in their source code, and in the same way in the above
example..

If A contained a B and B contained an A, which contains a B.......

Use pointers.

Ian

[Artie Gold]

twoeyedhuman111 1 wrote:

Okay so I guess doing things the way I'm doing them is bad design and
makes the compiler sick. Perhaps I could combine both classes into
one... The only differences between xbasednode and ybasednode are the
way they handle their input.

The xbasednode and ybasednode store sprites and sort them by x and y
respectively.

ybasednode's code is so unreadable right now, that I can't even
understand it...

xbasednode's code: (beware, it's very long for readability)
class xbasednode
{
public:
[snip] private:
int childside; // tells whether this is a right or left child
bool haschildren;
std::vector<spr ite*> itsdata;
ybasednode * parent; // the reason these are y
// based is so that x and y nodes
// repeat each other
ybasednode * rightnode;
ybasednode * leftnode;
t3h::rect itsarea;
};

Although you posted *way* too much code -- and you never really stated
what the problem was, I think I have an inkling as to what's going on.

Naturally, it's hard to evaluate your design (and at these prices, it
ain't gonna happen), but I immediately notice one thing: Your types are
mutually recursive in regards to *pointers* which is just fine.

The way to solve your problem is by judicious separation of declaration
and implementation. Your *implementation * code for xbasednode needs to
be able to see the *declaration* of ybasednode, and vice versa. This is
not a problem.

I would, however, recommend that you post a *minimal* extract (the
smallest possible one that gives you trouble) and you'll either solve it
by yourself in the process or someone here should be able to help you
quickly and easily.

HTH,
--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com (new post 8/5)
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

[twoeyedhuman1111]

Actually, I did solve it, with your help. I combined the two classes
into one. I'm not sure if I can really post what I did, since my brain
is racked, but I did solve the problem.

I learned that two classes cannot have each other as members and so I
combined the two classes and solved the problem.

So thank you very much for helping me! I got my problem fixed! yayay!!