forward declaration

I have read a few things about forward declaration from previous posts. I see that references and pointers can be used with forward declaration but not objects, probably due to the fact that the compiler won't know some details of the class (like the size).
But this doesn't compile:

Code:

class A {
   void fun(B& bclass) {
       bclass.data;
   }
};

class B {
    int data;
    A hey;
}

The errors (gcc):
error: Invalid use of undefined struct B
error: forward declaration of struct B

Is there a way to do what I want?

Another question is this. Is dynamic_cast generally recommended to be used, or does it have to much an cost? Can its exception (wrong casting) be handled so the program doesn't crush?

And finally, lets say you have a pointer to a class A. You point it on a derived class B : A. Can you determine with a function if the pointer points at a class of a or B?

class B;

Put that before you declare class A

You still can't use members before they are declared. This works (modulo .data being a private member of B):

Code:

class B;

class A {
    void fun(B& bclass);
};

class B {
    int data;
    A hey;
};

void A::fun(B& bclass) {
    bclass.data;
}

Lol, I did put it but forgot to post it. That is why I named the topic "forward declaration". I ll edit it

Originally Posted by tabstop

You still can't use members before they are declared. This works (modulo .data being a private member of B):

Code:

class B;

class A {
    void fun(B& bclass);
};

class B {
    int data;
    A hey;
};

void A::fun(B& bclass) {
    bclass.data;
}

Thanx!

Originally Posted by C_ntua

Another question is this. Is dynamic_cast generally recommended to be used, or does it have to much an cost? Can its exception (wrong casting) be handled so the program doesn't crush?

And finally, lets say you have a pointer to a class A. You point it on a derived class B : A. Can you determine with a function if the pointer points at a class of a or B?

Generally you design your classes polymorphically so that you never have to cast down to a derived type, however in the rare cases where you do need to downcast, you can check the runtime type of the object before you perform the cast using 'typeid'.

Some compilers require you to use a special flag to turn on RTTI though. Also notice that I included a virtual destructor in the super class. If you don't include at least one virtual function, typeid() probably won't report the actual runtime type of the object. (As you probably already know though, you should always include at least a virtual destructor)

Code:

#include <iostream>
#include <typeinfo>

class Super
{
public:
   virtual ~Super() {}
};

class Sub : public Super {};

int main()
{
   Super *obj = new Super;
   std::cout << typeid(*obj).name() << std::endl;
   
   if (typeid(*obj) == typeid(Super))
      std::cout << "Yes, this is a Super class." << std::endl;
   else
      std::cout << "No, this isn't a Super class." << std::endl;
   
   delete obj;
   
   obj = new Sub;
   std::cout << typeid(*obj).name() << std::endl;
   
   if (typeid(*obj) == typeid(Sub))
      std::cout << "Yes, this is a Sub class." << std::endl;
   else
      std::cout << "No, this isn't a Sub class." << std::endl;
   
   delete obj;
}

Thanx, that will do the trick.
Is it actually rare to downcast? I mean if you have a class Obj and derive from it class A: Obj and class B: Obj. Now, you want to have a list with both A and B objects. What other option do you have rather than having a Obj* pointer and down casting accordingly either to A* or B*? This is a common example I find (though for Java to be honest).

Virtual functions? Normally you don't care which derived class instance you are using as long as it can - in its way - do everything which the base class promises.

If you find yourself needing to downcast often, that's usually a sign of bad object-oriented design practices. Sometimes you do genuinely need to downcast, but you usually try to avoid this as much as possible.

Maybe if you mentioned what your program is doing and why you are trying to downcast, someone could suggest a more appropriate polymorphic approach (if possible).

What I do is have a list of objects from which the user will choose something. If he chooses the wrong type of object then an error message should occur. If not then the data of the object should be accessed.
Now that I think of it, I could have a virtual function getData() and return accordingly the data from the class, so I don't need to downcast at all. Like:

Code:

class A {
  virtual void getData() (int& data1, int& data2) {
     cout << "no data");
  }
};
class B: A {
  int dataB;
  void getData() (int& data1, int& data2) {
      data1 = dataB;
  }
};

class C: A {
    int dataC1, dataC2;
    void getData (int& data1, int& data2) {
       data1 = dataC1;
       data2 = dataC2;
  }
};

Though this code seems to have some downsides. Like what if every class has a different type of data?

Such things are usually solved through templates, I think (classes having different data):

Code:

template<typename T> void HandleData(CMyClass<T>& data)
{
    T data = data.GetData();
    // ...
}

It all depends on how you should use the data, I think.
You could also use a virtual function IsValid to get a bool if the data is valid or not.
Or GetData can throw an exception.

Hope these suggestions help some.

Again, normally you wouldn't think about your classes as holders of data (with getters/setters, in which case it is hard to avoid knowing the exact type of things) rather than as performers of actions. Compare having a Mage with method Get/SetSpellDamage and a Warrior with method Get/SetSwordAttackDamage, vs both having a method (Attack/Upgrade) or something like that.

Hmm, I get your point of view. I ll follow what you say anon using equip() function to handle the data of my list<Item>.
And yes the template should solve the rest of the problems, I suppose.

Atm I am just building a D&D 4E character builder/arena fight, just to see the features of C++. The program is kind of easy so it could be done in a lot of ways. I just try to make it as OOP as possible and avoid from now bad programming techniques.

I would like to ask though why is using virtual functions a better method than downcasting, since you have typeid() to access data safely without crashing the program with a dynamic_cast. More things to convince me

Also, when a object of a certain class is created what exactly happens?
1) Space is allocated for all its variables and pointers, including the this pointer.
2) Space is allocated to store the address of the function in the class and its manual and default constructors/deconstructors.
3) So, if the function is virtual, then the address of the derived class's function is stored in the place of the base class virtual function
4) If an object is declared inside an object, then space is allocated with the above steps
5) In run time, the constructor assigns values and anything else it wants
6) Space is freed when the object goes out of scope. So I suppose the compiler finds where the scope ends and calls the deconstructor function there.

Originally Posted by C_ntua

I would like to ask though why is using virtual functions a better method than downcasting, since you have typeid() to access data safely without crashing the program with a dynamic_cast.

Conceptually, I like the example of a man entering a restaurant. He looks at the next table and sees someone eating a delicious meal. Then he calls the waiter over and says, "if that customer is having spaghetti, I want spaghetti, but if he is having lasagna, I want lasagna, but then if he is having...", reciting the menu until the point where the dish matches what the customer is eating. This is like the approach of using dynamic_cast to determine the correct type of MenuItem that the other customer has, and then ordering that one. The use of a virtual clone() function, on the other hand, is like the man saying to the waiter "I'll have what he's having!"

Originally Posted by C_ntua

I would like to ask though why is using virtual functions a better method than downcasting, since you have typeid() to access data safely without crashing the program with a dynamic_cast. More things to convince me

For one, more abstraction or encapsulation.
Secondly, very likely, it's much faster.
And thirdly, polymorphism was invented to be able to manipulate objects without knowing the exact type (even better with static polymorphism). In other words, polymorphism exists so that you shouldn't have to do downcasts!

1) Space is allocated for all its variables and pointers, including the this pointer.

Space is allocated for all member variables. "this" is not a member variable and thus no space is allocated for it. "this" is just a keyword that equals the address in memory where the instance of the class is stored. Basically it's just &myobj, where myobj is the instance of your class on the stack.

2) Space is allocated to store the address of the function in the class and its manual and default constructors/deconstructors.

No, functions are global. They do not belong to a specific instance. They are functions with an extra parameter for "this".
Constructors are the same - they, too, are functions.

3) So, if the function is virtual, then the address of the derived class's function is stored in the place of the base class virtual function

Well, I suppose in a way.
A usual approach to this (how virtual functions work are implementation defined!) is a v-table. Basically, the compiler stores a pointer to the correct function to be called for each instance of the class. When you create a Derived object, it stores the address of the Derived's function. The same applies if it's Base. Then Base's function is stored in the v-table.
However, this isn't guaranteed since each compiler vendor can do as they want, just as long as it works.

4) If an object is declared inside an object, then space is allocated with the above steps

Yes, with the corrections. If object B is inside object A, then object B will be constructed while A is still constructing. When B finished constructing, only then will A finish constructing.

5) In run time, the constructor assigns values and anything else it wants

Yes, the constructor's job is to make sure that the object is ready-to-use after you finish creating it.

6) Space is freed when the object goes out of scope. So I suppose the compiler finds where the scope ends and calls the deconstructor function there.

Yes, this applies to any objects placed on the stack.