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;
}
why would you ever upcast an object pointer?
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]
[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]
In your given example you can do the following :
In words its used for polyomrphism, which is used for generalization or uniformity.
#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.
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.
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.
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.
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.
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.
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
Popular Topics
Advertisement