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.

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.

--
Mats

---

It's true that it can get tricky, but I'd be inclined to write a tricky implementation, instead of inconveniencing the client of the class.

I don't understand exactly what you example is, but I'm sure it could be resolved by some combination of nothrow new, a try catch function body, and separating out each discrete step into it's own try catch combo. If you explain it better, I'm sure I could provide a solution.

Quote:

---

Originally Posted by brewbuck

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.

---

I agree with most of what you said, but not with this rule. Certainly, sub objects should clean themselves up in their own destructors as much as possible. But catch and rethrow is a perfectly valid approach for when the former is impossible or suboptimal. Also, a constructor may receive ownership of an object. In such a case, it is the constructor's responsibility to clean up the object if an exception is thrown. There is no way around it.

Quote:

---

Originally Posted by King Mir

I agree with most of what you said, but not with this rule. Certainly, sub objects should clean themselves up in their own destructors as much as possible. But catch and rethrow is a perfectly valid approach for when the former is impossible or suboptimal.

---

I can't imagine this "impossible or suboptimal" case. Do you have an example?

Quote:

---

Also, a constructor may receive ownership of an object. In such a case, it is the constructor's responsibility to clean up the object if an exception is thrown. There is no way around it.

---

If an object is owned, it should be referenced through a smart pointer which manages ownership.

EDIT: Also, I question whether ownership should actually be transferred if a constructor fails. Maybe the caller would like a chance to do something, instead of having the object thrown away by what looked like a simple constructor call.

Quote:

---

Originally Posted by brewbuck

I can't imagine this "impossible or suboptimal" case. Do you have an example?

---

Any bottom teer object, such as a file handler, a network handler, or a memory manager.

Really any constructor that does anything besides assign values in its body.

Quote:

---

If an object is owned, it should be referenced through a smart pointer which manages ownership.

---

That would require the class and the client code to share the same smart pointer implementation. Also that would not work for implementing the smart pointer itself.

Quote:

---

Originally Posted by brewbuck

EDIT: Also, I question whether ownership should actually be transferred if a constructor fails. Maybe the caller would like a chance to do something, instead of having the object thrown away by what looked like a simple constructor call.

---

At that point it's too late. If the ownership was passed from a smart pointer that smart pointer would have already released ownership when the constructor receives the argument. If it is from a call to new, that pointer is not stored anywhere except as a function argument. The options are to either free the memory, or to pass the pointer in the exception. Freeing the memory usually makes more sense.

Quote:

---

Originally Posted by King Mir

Any bottom teer object, such as a file handler, a network handler, or a memory manager.

---

Can you give a more specific example? I can't imagine any kind of clean-up from a failed constructor that can't be handled with some simple containers.

Quote:

---

That would require the class and the client code to share the same smart pointer implementation. Also that would not work for implementing the smart pointer itself.

---

Obviously the very, very bottom of the stack is going to have to deal with exceptions. Exception safety COMES from somewhere, yes.

As far as smart pointers... In the case we're talking about, an auto_ptr is all that is required. It's part of the standard library. Even if it wasn't, I don't see what the problem is from an API standpoint. If the caller has to wrap up a pointer in some smart pointer class to pass it to a function, then so be it.

Quote:

---

Originally Posted by King Mir

At that point it's too late. If the ownership was passed from a smart pointer that smart pointer would have already released ownership when the constructor receives the argument.

---

Hence the other part of what I said -- acquire resources in the right order. Transfer of ownership from one smart pointer to another is exception-free. Therefore, if this is the last thing you do in your constructor, you're fine.

Quote:

---

Originally Posted by brewbuck

Can you give a more specific example? I can't imagine any kind of clean-up from a failed constructor that can't be handled with some simple containers.

---

Unfortunately I can't give you an example from code I have actually written.

Containers only manage memory. If a constructor call uses other resources, like files, a network connection, or something similar, then those resources must be cleaned up. A constructor's catch block is the only place to do this.

Case point: fstream.

Like I said, these are generally bottom teer objects.

Quote:

---

As far as smart pointers... In the case we're talking about, an auto_ptr is all that is required. It's part of the standard library. Even if it wasn't, I don't see what the problem is from an API standpoint. If the caller has to wrap up a pointer in some smart pointer class to pass it to a function, then so be it.

---

Quote:

---

Originally Posted by brewbuck

Hence the other part of what I said -- acquire resources in the right order. Transfer of ownership from one smart pointer to another is exception-free. Therefore, if this is the last thing you do in your constructor, you're fine.

---

But what if the class doesn't use auto_ptr? What if it uses something else. It should not matter to the outside what kind of smart pointer is used internally. Therefore a raw pointer is best. But raw pointers require extra care with exception safety. So we use extra care by using catch and rethrow.

Quote:

---

Originally Posted by King Mir

Containers only manage memory. If a constructor call uses other resources, like files, a network connection, or something similar, then those resources must be cleaned up. A constructor's catch block is the only place to do this.

---

Memory is not that different from any other resource. Anything which safely manages a resource could be called a "container." What I'm saying is that exception safety should be handled at the lowest possible level. If your file manager is at this level, then obviously your file manager is going to have to handle exceptions.

The point is that by building smart, exception-safe "bottom tier" objects as you say, you can easily propagate exception safety upward in the design.

Quote:

---

But what if the class doesn't use auto_ptr? What if it uses something else. It should not matter to the outside what kind of smart pointer is used internally.

---

If the class doesn't use auto_ptr, then the class does not conform to the requirements of the code it is trying to call. You have to draw a line somewhere. Again, none of this REQUIRES that a client class maintain this pointer in an auto_ptr. The condition is simply that once it is passed to the constructor, it is owned by that constructed object. If the caller had a raw pointer, then the caller just has to "forget" the reference. If you're not used to using smart pointers, you are already skilled at doing that.

Quote:

---

Therefore a raw pointer is best. But raw pointers require extra care with exception safety. So we use extra care by using catch and rethrow.

---

I hate trying to imagine all the possible paths through code during an exception, and figuring out what resources might leak or not. In my opinion exceptions should not be used to ensure proper resource release. Instead, all objects should be constructed out of other, completely exception-safe objects.

Quote:

---

Originally Posted by brewbuck

Memory is not that different from any other resource. Anything which safely manages a resource could be called a "container." What I'm saying is that exception safety should be handled at the lowest possible level. If your file manager is at this level, then obviously your file manager is going to have to handle exceptions.

The point is that by building smart, exception-safe "bottom tier" objects as you say, you can easily propagate exception safety upward in the design.

---

My point is that "any object constructor that does anything other than assign values to members" is a big enough exception that your simple rule doesn't seem to be useful. On everything else I agree.

Quote:

---

If the class doesn't use auto_ptr, then the class does not conform to the requirements of the code it is trying to call. You have to draw a line somewhere. Again, none of this REQUIRES that a client class maintain this pointer in an auto_ptr. The condition is simply that once it is passed to the constructor, it is owned by that constructed object. If the caller had a raw pointer, then the caller just has to "forget" the reference. If you're not used to using smart pointers, you are already skilled at doing that.

I hate trying to imagine all the possible paths through code during an exception, and figuring out what resources might leak or not. In my opinion exceptions should not be used to ensure proper resource release. Instead, all objects should be constructed out of other, completely exception-safe objects.

---

Yes, you can use auto_ptr as a transfer object for your pointer. It does have the advantage of providing that exception safety. But it is still more optimal to use raw pointers. It's a trade off. Sometimes one option is better, sometimes another. When writing an API, using a raw pointer is easier for the client, but harder for the API writer.

You can write a smart pointer without a single try...catch. As long as every resource handling class deals with exactly one resource, you can write completely exception-safe code without a single try...catch. If any class allocates more than one resource and wants to manage them all, it will have to use try...catch. brewbuck's rule is correct and universal.