How to access derieved class member from base class pointer

Hi,

I have a problem in accessing derived class member from base class pointer.....

I have two classes as follow:

Code:

---


class  A
{
};

class B : public A
{
public:

void set(char *);
};

---

I want to access set(char*) function of class B with the help of A class pointer as follow:

Code:

---


 B *b = new B;
A *a = dynamic_cast<B *>(b);

a->set(char *);

---

But this is giving error that A class don't have any member set(char *)................

Can anybody tell where I am wrong............

Thanks

That's because you can't do that. If your variable is of type A it can't see items of type B. You have to cast it and save it as an object of type B.

Talking about Type A and Type B makes me feel like I'm talking about blood types.... lol.

I'm not sure why you would do that. Are you trying some sort of polymorphism?

Do you mean something like this?:

Code:

---

void f()
{
    B *b = new B;
    g(b); // implicit cast to base
}
void g(A *a)
{
    B *bb = dynamic_cast<B *>(a);
    bb->set("Must be a B!");
}

---

Thanks for your reply...........

Actually I want above so because I have used this functionality in a function whose return type is A*....

i.e ..

Code:

---


A* C :: ABC()
{
  B *b = new B;
A *a = dynamic_cast<B *>(b);
a->set(char *);

 return a;
}

---

Ignore what is class C........Actually this is part pf project...........so I have to return object of A only.......

Thanks

If A* does not have a set method, why do you want to upcast before you are done working with the derived class?

Code:

---

A* C :: ABC()
{
  B *b = new B;
  b->set(char *);

    return b; //implicitly upcast, hopefully
}

---

In your code you are actually dynamically casting a B pointer into a B pointer and then implicitly into a A pointer.

However, if the function creates a new B object and accesses methods that only B has, I don't see why the return type should be a pointer to A. I would return B* and leave it up to the user to decide whether to assign the return type to A* or B* (that is, if your function is not more complicated, creating an unknown type derived from A).

Actually, if you want "proper" polymorphic behaviour (and if you are using inheritance, that's _MOST LIKELY_ what you want), then the correct thing is to declare a virtual function set() in the class A. This can be a pure virtual (that is, you can't actually CALL the virtual function in A, but it's there as a "place-holder" for derived classes).

Then there will be no reason to have any casts, and the behaviour is predictable, doesn't rely on "knowing which class something is", etc. etc.

--
Mats

Quote:

---

Originally Posted by matsp

Actually, if you want "proper" polymorphic behaviour (and if you are using inheritance, that's _MOST LIKELY_ what you want), then the correct thing is to declare a virtual function set() in the class A. This can be a pure virtual (that is, you can't actually CALL the virtual function in A, but it's there as a "place-holder" for derived classes).

---

One just has to remember that when doing so, the class becomes abstract and can't be created, just inherited from.

Quote:

---

Originally Posted by Elysia

One just has to remember that when doing so, the class becomes abstract and can't be created, just inherited from.

---

Yes, using pure virtual has this as a side-effect. Hide the destructor of class A, and that problem is automatically detected by the compiler.

Or make your own error handling in the class itself - so that calling A::set() gives a suitable error message and stops the application.

But my point was rather that if you have a pointer to a base-class and you want to call functions that are only in the derived class, then there's [usually] something wrong in the base-class.

--
Mats

Quote:

---

Originally Posted by matsp

But my point was rather that if you have a pointer to a base-class and you want to call functions that are only in the derived class, then there's [usually] something wrong in the base-class.

---

I agree on that. The function should return a B*, and the main program should decide whether to use an A* pointer in some function, and if then calling a function in B, then it's probably likely that there's more than one class derived from A and then virtual functions is the way to go.

Another thing: if the set method is supposed to be called only after creating the object, you might just give parameters to the constructor and have it set right there.

Quote:

---

Originally Posted by anon

Another thing: if the set method is supposed to be called only after creating the object, you might just give parameters to the constructor and have it set right there.

---

Depends. If you need to be exception safe, that may not work. But yes, that's an option in some situatons.

--
Mats

Quote:

---

Originally Posted by matsp

Depends. If you need to be exception safe, that may not work. But yes, that's an option in some situatons.

--
Mats

---

Constructors can be exception safe It's just trickier in some cases.

Quote:

---

Originally Posted by King Mir

Constructors can be exception safe It's just trickier in some cases.

---

Yes, they CAN be - but as you say, it can get tricky - and it's often easier to solve that problem with a two-stage constructor, so that if you have an exception, you KNOW what has been done and what hasn't - e.g. have you filled in the "char *" value, or is it not filled in. If you do "new B" and B's constructor sets the "char *" member variable ptr = 0, then you know that part isn't going to cause an exception, but

Code:

---


ptr = new char[strlen(s)+1]

---

could throw an exception. Now, since ptr hasn't been set to anything sensible [assuming we didn't assign it twice], so we don't know if we should delete ptr or not.

--
Mats

Quote:

---

Originally Posted by matsp

Yes, they CAN be - but as you say, it can get tricky - and it's often easier to solve that problem with a two-stage constructor, so that if you have an exception, you KNOW what has been done and what hasn't - e.g. have you filled in the "char *" value, or is it not filled in. If you do "new B" and B's constructor sets the "char *" member variable ptr = 0, then you know that part isn't going to cause an exception, but

Code:

---


ptr = new char[strlen(s)+1]

---

could throw an exception. Now, since ptr hasn't been set to anything sensible [assuming we didn't assign it twice], so we don't know if we should delete ptr or not.

---

Simple rule -- don't catch exceptions in your constructors. Let them propagate out. If doing this would lead to a resource leak, it means you are not acquiring resources properly.

For instance, never use new[] directly, always use boost::scoped_array or std::vector.

For the most part, total safety of constructors can be guaranteed by initializing members in the proper order and using appropriate exception-safe members. Once you build exception-safety in at the low level it will propagate upward in your design.