why would you ever upcast an object pointer?

Started by
5 comments, last by way2lazy2care 12 years, 10 months ago
i dont see the point or why you would ever want to upcast an object for example



class Shape
{
.....
};


class rectangle : public shape
{
....
};


int main()
{
rectangle object1;
Shape *shapePtr = &object1;

return 0;
}

Advertisement
Pseudo why:

[source lang="cpp"]class object;

class object_manager
{
array_of_objects[100];
}


class cool_object : (inherits_from) object
{
cool_method();
}


for each object in object_manager
{
upcast_to_cool_object(object)->cool_method(); //oops!

}

[/source]
[size="2"]I like the Walrus best.
maybe i'm retarded.....but i still dont get it..anyone else :(?
In your given example you can do the following :

#include <algorithm>
//...

struct IShape{
virtual void draw()const = 0;
//...more virtual method
};

struct Rectangle : IShape{
void draw()const{ GraphicsAPI.fillRect(...); }
//...
}
struct Circle : IShape{
void draw()const{ GraphicsAPI.fillCircle(...); }
}

void drawShape(const boost::shared_ptr<IShape>& shape){ shape->draw(); }

int main(){
std::vector< boost::shared_ptr<IShape> > shapes;
shapes.push_back( new Rectangle() );
shapes.push_back( new Circle() );
std::for_each( shapes.begin(), shapes.end(), draw );
return 0;
}


In words its used for polyomrphism, which is used for generalization or uniformity.
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github
There are cases where there is a class in charge of distributing instances of some base class type to other classes who need to work with a specific subclass.

This is common in systems that are meant to be scalable, that is, systems that allow the possibility of adding new classes to a program without having to touch the code that already exist).

To do that, such system only deals with base classes. When a new class must be added, you just implement a factory to create the new sub class instance and return a base object to the manager, which in turn might (or not) do some basic processing on the base class instance and then distribute it to some other new class (through it's base class) that knows the sub class type.

The receiver then up-casts the base object to the sub-class it knows.

If someone can put it clearer than that I'll lick my shoes. :P
[size="2"]I like the Walrus best.
To simplify what everyone is saying... the benefit is being able to store different types of objects in one container.

You would create a container that holds pointer to the base object. Then this allows you to store any object that is derived from the base. But unless you cast the objects in the container back to they're actual type, you can only use the base classes methods.

But if you mean simply upcasting an object, you typically wouldn't unless you specifically want to use that types implementation of it's methods.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
to further what others are saying and to elaborate on what others are saying/expand on a previous example. edit: wow this is awfully redundant.

Shapes are a great example of why you might want such a thing. Shapes are all unique in their definition, but they all have a lot of similarities. They are all made up of lines. They all have areas. Often shapes is taken as concave shapes which brings on a whole new set of shared properties that all might be useful to something that doesn't care if a shape is a circle or a rectangle.

It's also tremendously useful to prevent method overloading for methods that are identical except for taking in a different parameter type.

This topic is closed to new replies.

Advertisement