views:

319

answers:

4

Hay Dear!

First of all have a look at the following code (in this code shape is the base class and line is the derived class)

void drawshapes(shape sarray[],int size)
{
for(int i=0;i< size; i++)
    sarray[i].draw();
   }
main()
{
   line larray[10];
   larray[0]=line(p1,p2);//assuming that we have a point class
   larray[1]=line(p2,p3);
   ..........
   drawshpes(larray,10);
   }


when we compile this program the draw method of shape would be called at first then program terminates. why it terminates ? why we can not implement polymorphism without base class pointer or reference what is the technical reason for this? what compiler will do if we are trying to implement polymorphism with the array of objects ? please explain in much understandable manner with examples. I will be very thankful.

+3  A: 

You cannot pass an array of line instead of an array of shape. You must use array of pointers. This happens because when the function tries to access the second member, it does *(sarray + sizeof(shape)) instead of *(sarray + sizeof(line)), that would be the correct way to access the second element of an array of line.

sergiom
i am expecting detailed answer, this answer is not helpful.
Zia ur Rahman
This answer is quite helpful, reread it until you understand. An array of `derived` is not an array of `base`, even if each `derived` is a `base`. There is another problem in your code, that is maybe what you are more interested in now, why does polymorphism require reference/pointer... but this answer is quite valuable in itself.
David Rodríguez - dribeas
+1  A: 

You want something like this:

void drawshapes(shape *sarray[],int size)
{
   for(int i=0;i< size; i++)
      sarray[i]->draw();
}

main()
{
   shape *larray[10];
   larray[0] = new line(p1,p2);//assuming that we have a point class
   larray[1] = new line(p2,p3);
   ..........
   drawshapes(larray, 10);
   // clean-up memory
   ...
}
Maurits Rijk
+4  A: 

First: you're mixing two concepts: polymorphism, and value vs. reference semantics.

Runtime polymorphism

Polymorphism comes in many shapes. Depending on the runtime you use, other options are available.

An interpreted language (like Ruby, Python, Javascript, ...) allows for 'duck typing': if an object merely has a method called foo, you can call it. Typically these languages do garbage collection, so the notion of pointers vs. objects isn't too relevant.

C++ has a different viewpoint: polymorphism is allowed, but in a more strict way. Enforcing a common base class (which may be abstract) allows the compiler to check the semantics of your code: this way the compiler assures that you really meant the foo method which implements the intended interface, and not some mishmash of foos.

This polymorphism is realized through the use of a virtual function: a pointer to a function, which may vary amongst implementations. The caller of foo will first have to look up the value of the function pointer, and then jump to that function.

So far for polymorphism.

Containment

Now for containment: if you create an array of line objects in C++, these objects are right next to each other in memory; they're contained by value. When you pass the array to a function, the called function can only receive an array of the same type. Otherwise, taking a step of sizeof(shape) into the array we would end up in the mid of a line.

In order to fix that, you can contain the objects 'by reference' - in C++ we use pointers for that.

Compile-time polymorphism

But there is another way to achieve polymorphic functions: templates. You can write your drawshapes function with a template argument that says which type of object you are using:

template< typename tShape, size_t N > 
void drawshapes( tShape (&aShapes)[N] ) {
    for( tShape* shape=aShapes; shape != aShapes+N; ++shape ) {
        shape->draw();
    }
}

(Note: there are stl functions to simplify this, but that's out of the scope of the question.

std::for_each( shapes, shapes+10, mem_fun_ref( &shape::draw ) );

)

xtofl
+3  A: 

You are asking a question and providing a code example that fails but for a different reason. From the wording of your question:

Why are references/pointers required for polymorphism?

struct base {
   virtual void f();
};
struct derived : public base {
   virtual void f();
};
void call1( base b ) {
   b.f(); // base::f
}
void call2( base &b ) {
   b.f(); // derived::f
}
int main() {
   derived d;
   call1(d);
   call2(d);
}

When you use pass-by-value semantics (or store derived elements in a base container) you are creating copies of type base of the elements of type derived. That is called slicing, as it resembles the fact that you have a derived object and you slice/cut only the base subobject from it. In the example, call1 does not work from the object d in main, but rather with a temporary of type base, and base::f is called.

In the call2 method you are passing a reference to a base object. When the compiler sees call2(d) in main it will create a reference to the base subobject in d and pass it to the function. The function performs the operation on a reference of type base that points to an object of type derived, and will call derived::f. The same happens with pointers, when you get a base * into a derived object, the object is still derived.

Why can I not pass a container of derived pointers to a function taking a container of base pointers?

_Clearly if derived are base, a container of derived is a container of base.

No. Containers of derived are not containers of base. That would break the type system. The simplest example of using a container of derived as container of base objects breaking the type system is below.

void f( std::vector<base*> & v )
{
   v.push_back( new base );
   v.push_back( new another_derived );
}
int main() {
   std::vector<derived*> v;
   f( v ); // error!!!
}

If the line marked with error was allowed by the language, then it would allow the application to insert elements that are not of type derived* into the container, and that would mean lots of trouble...

But the question was about containers of value types...

When you have containers of value types, the elements get copied into the container. Inserting an element of type derived into a container of type base will make a copy of the subobject of type base within the derived object. That is the same slicing than above. Besides that being a language restriction, it is there for a good reason, when you have a container of base objects, you have space to hold just base elements. You cannot store bigger objects into the same container. Else the compiler would not even know how much space to reserve for each element (what if we later extend with an even-bigger type?).

In other languages it may seem as this is actually allowed (Java), but it is not. The only change is in the syntax. When you have String array[] in Java you are actually writting the equivalent of string *array[] in C++. All non-primitive types are references in the language, and the fact that you do not add the * in the syntax does not mean that the container holds instances of String, containers hold references into Strings, that are more related to c++ pointers than c++ references.

David Rodríguez - dribeas