|
|
| cyclic dependencies |
|
Frank Drebin
Member #2,987
December 2002
|
how can i solve this problem: //file1.cpp class a void a::do_something_with_b() //file2.cpp class b void b::do_something_with_a() |
|
Thomas Fjellstrom
Member #476
June 2000
|
put the class declaration in thier own .h file, and include then where needed. -- |
|
mEmO
Member #1,124
March 2001
|
Are you sure you're not confusing class declarations and objects? A class is a template for an object, not the object itself. To use it properly, do like this: class Foo { public: int var; }; Foo bar; bar.var = 2; Just to make sure, though. --------------------------------------------- |
|
Torbjörn Josefsson
Member #1,048
September 2000
|
There's No way to protect against this kind of 'logical bug' Simply don't write the program in this way. It's the same thing as writing: void do_something(){ do_something(); } It's a recursive situation without any exit condition. If you want to make sure each one is only called once (I'm not sure what you're trying to do), you have to perform a check to see that it doesn't continue forever - maybe pass along an integer counter in the call, increment it for each call, and see if it exceeds some max value for recursive calls?
-- |
|
Frank Drebin
Member #2,987
December 2002
|
perhaps the example i gave is not very well |
|
Thomas Harte
Member #33
April 2000
|
So, you're problem was not one of functions calling each other, but one where the first class didn't know the definition of the other? Don't forget that you can use forward defintions, like : class Elephant; class Mouse { ... Elephant *ScaredCreature; ... }; class Elephant { ... Mouse *ScaryCreature; ... }; i.e. if the compiler really only needs to know that Elephant exists as a class (rather than being fussed about members), then that is all you need to tell it. You know how I found that out? I had a little hunchback at the office. [My site] [Tetrominoes] |
|
Frank Drebin
Member #2,987
December 2002
|
yes with a pointer to a class this may work but when you declare a variable of that class it doesn't class Elephant; class Mouse class Elephant |
|
X-G
Member #856
December 2000
|
Frank Drebin said: yes with a pointer to a class this may work but when you declare a variable of that class it doesn't
There's a good reason for that. For one thing, each of the resulting classes would be infinitely large, as they contain each other. -- |
|
Frank Drebin
Member #2,987
December 2002
|
so how can i break a dependencie like that: |
|
X-G
Member #856
December 2000
|
Obviously, your only chance is to use pointers. -- |
|
gillius
Member #119
April 2000
|
If you need A to know about B and B to know about A you CANNOT have A contain B and B contain A. That makes no sense and it would go on forever. You must use pointers or references and you must use forward delcarations as was shown to you earlier. Do not place all classes in one big header or whatever you were considering. In your class header, instead of doing #include "Class.h", replace it with class Class; as much as possible. As long as the class you are defining does not inherit from Class, does not contain a Class object, and does not have any methods taking a copy of a Class object (ie only Class* and Class& are seen), you can and should use forward declarations. Gillius |
|
miran
Member #2,407
June 2002
|
And of course you should use include guards (or whatever they're called):
-- |
|
Frank Drebin
Member #2,987
December 2002
|
o.k. but i'm not very good in pointers, so when i just declare a pointer to the bullet class in the player class how can i call then the bullet.fireit() method |
|
23yrold3yrold
Member #1,134
March 2001
|
Quote: o.k. but i'm not very good in pointers, so when i just declare a pointer to the bullet class in the player class how can i call then the bullet.fireit() method Well, first you need to create a bullet (using new), but I'm sure you knew that. Then you can call -- |
|
Frank Drebin
Member #2,987
December 2002
|
1. so i can use 2. and when theres a global object bullet1 |
|
23yrold3yrold
Member #1,134
March 2001
|
1. No. You need to have declared the class, not just a forward declaration (I call these class prototypes as they are like function prototypes. I may be the only person that does that, though You can organize it like this, just as an example:
You can define fireit() (and all of Bullet's other functions) in a seperate file if you want. But if you want to access Bullet's members, you must declare the members first. 2. Sounds right .... -- |
|
X-G
Member #856
December 2000
|
Creepy Disembodied Bearded Tycho Head said: I call these class prototypes
You should call them classes, simple enough. -- |
|
23yrold3yrold
Member #1,134
March 2001
|
Nonono ... // class prototype class Bullet;
// class declaration class Bullet { public: Bullet(); ~Bullet(); void fireit(); };
// class definition Bullet::Bullet(){ // blah blah blah } Bullet::~Bullet(){ // blah blah blah } void Bullet::fireit(){ // blah blah blah } Geddit? -- |
|
X-G
Member #856
December 2000
|
How interesting, then, that there are no such in the code snippet. -- |
|
23yrold3yrold
Member #1,134
March 2001
|
Huh? Look at Frank's last post. I know I didn't use one; it wouldn't have worked. That was the point -- |
|
X-G
Member #856
December 2000
|
Just call them forward declarations like everyone else, all right? -- |
|
23yrold3yrold
Member #1,134
March 2001
|
I called one thing a class prototype, and another thing a class declaration. Which one is the forward declaration, can we call function prototypes that, and what do you call the other class thing (whichever isn't a declaration)? -- |
|
X-G
Member #856
December 2000
|
s/class prototype/forward declaration of class x/ -- |
|
|