polymorphism

R

ravinderthakur

hi experts,


just out of curosity why polymorphism is allowed to work only with
pointers and references to the objects and not with the objects itself.


what are the reasons behind forbidding this behavior.


is this restriction anyway related to the ABC.

thanks
rt
 
K

Kai-Uwe Bux

hi experts,


just out of curosity why polymorphism is allowed to work only with
pointers and references to the objects and not with the objects itself.


what are the reasons behind forbidding this behavior.


is this restriction anyway related to the ABC.

thanks
rt

An object is a region of memory, thus it has a certain size to be determined
at compile time, i.e., when you write

MyWonderfulClass my_variable;

the compiler determines how much memory to allocate on the stack for
my_variable. That rules out polymorphism for variables.

If one could overload the dot-operator, one could create smart references
(in addition to smart pointers) to emulate polymorphic objects. However, as
of now, we cannot overload the dot-operator.


Best

Kai-Uwe Bux
 
S

Srini

hi experts,
just out of curosity why polymorphism is allowed to work only with
pointers and references to the objects and not with the objects itself.

what are the reasons behind forbidding this behavior.

is this restriction anyway related to the ABC.

thanks
rt

By polymorphism, do you mean runtime polymorphism?

Pointers and references can point to any derived class object in the
class heirarchy. This is where the dynamic type of the object pointed
to and runtime polymorphism, comes into picture. An object(in the
context you've mentioned) in itself does not have a dynamic type. This
is my understanding of this topic. I might not be completely correct.

Srini
 
R

ravinderthakur

if that is the case then why a derived class object can be assigned to
a base class object?

after all if a pointer to a derived class object is a pointer to a base
class object then same
in the same token a derive class object is also a base class object. it
can also access the
vtable for doing polymorphism.

i want to know of that one big condition due to which c++ has put a
check for not allowin
polymorphism via object and only through pointers/referces.

thanks
rt
 
R

ravinderthakur

one counter argument kai:

the compiler can determine at the compile time if the class of the
object that is being created on the stack contains the virtaul function
and hence CAN put a pointer to vtable at the end of the object. after
all only a single pointer to the vtable needs to be put in to the
object. so the size of the objects of this class can be determinded at
the compile time.

so the question still remains:

why polymorphism dosn't work with objects in c++.

thanks
rt
 
S

Srini

if that is the case then why a derived class object can be assigned to
a base class object?

This causes object slicing.
after all if a pointer to a derived class object is a pointer to a base
class object then same in the same token a derive class object is also a base class object. it
can also access the vtable for doing polymorphism.

No. This is not correct. A derived class object *contains* a base class
*sub*-object.
i want to know of that one big condition due to which c++ has put a
check for not allowin
polymorphism via object and only through pointers/referces.

thanks
rt

As I said before, what I said is my understanding. But what you've
mentioned above are not valid.

Srini
 
K

Kai-Uwe Bux

one counter argument kai:

the compiler can determine at the compile time if the class of the
object that is being created on the stack contains the virtaul function
and hence CAN put a pointer to vtable at the end of the object. after
all only a single pointer to the vtable needs to be put in to the
object. so the size of the objects of this class can be determinded at
the compile time.

so the question still remains:

why polymorphism dosn't work with objects in c++.

Ultimately: because the standard specifying c++ says so.

However, if you want a technical reason it is this: c++ has copy-semantics.
The most straight forward way of implementing copy semantics is to require
slicing of objects in assignments like

base_class_obj = derived_class_obj;

The reason is that base_class_obj provides memory on for only those *data*
members of the derived class that are inherited from the base class. What
you do about vtable pointers is immaterial.


Now, one could specify a different semantics for the above assignment
(preserving copy-semantics and avoiding sllicing) but that would require a
little more work on the part of the compiler and some overhead in
assignments at run-time. In C++ the decision was made that you do not want
to pay that additional cost for an assignment operation.


Best

Kai-Uwe Bux
 
R

ravinderthakur

thanks for ur reply kai,

few more question is in order:

a) is there some book that discusses this aspect of why polymorphism
was not allowed for objects. (of the type of the The Design and
Evolution of C++) ?

b)it is generally adviced that it is better to create objects on stack
rather than on the
heap. (due to robust handling in case of exceptions, lesser heap
fragmentation ,less memory management by programme etc.)
so does disallowing this feature causes invitation to some of these
unnecessary problem? was this feature impossible to implement in the
c++ language itself???

thanks
rt
 
K

Kai-Uwe Bux

few more question is in order:

a) is there some book that discusses this aspect of why polymorphism
was not allowed for objects. (of the type of the The Design and
Evolution of C++) ?

Sorry, I don' know.
b)it is generally adviced that it is better to create objects on stack
rather than on the
heap. (due to robust handling in case of exceptions, lesser heap
fragmentation ,less memory management by programme etc.)
so does disallowing this feature causes invitation to some of these
unnecessary problem?

I do not understand this question. Are you sure you meant "does disallowing
this feature cause ..." and not "would allowing this feature cause ..."?
was this feature impossible to implement in the c++ language itself???

Most certainly, it was not *impossible* to implement. As I said in my first
post, I think one could achieve pretty much the behavior that you have in
mind by overloading the dot-operator. There are, to my knowledge, no
compelling technical reasons for not allowing that (I might be mistaken,
though).


Best

Kai-Uwe Bux
 
G

Greg

if that is the case then why a derived class object can be assigned to
a base class object?

after all if a pointer to a derived class object is a pointer to a base
class object then same
in the same token a derive class object is also a base class object. it
can also access the
vtable for doing polymorphism.

i want to know of that one big condition due to which c++ has put a
check for not allowin
polymorphism via object and only through pointers/referces.

thanks
rt

No, a derived object cannot be assigned to a variable of a base class
because the base class variable has only enough allocated space for the
base class members and not any additional members declared in the
derived class. Performing a copy of a derived class to a base is called
object "slicing" and it is a runtime error since the copied object is
now in an undefined state.

Greg
 
K

Kai-Uwe Bux

Greg said:
No, a derived object cannot be assigned to a variable of a base class
because the base class variable has only enough allocated space for the
base class members and not any additional members declared in the
derived class. Performing a copy of a derived class to a base is called
object "slicing" and it is a runtime error since the copied object is
now in an undefined state.

AFAIK, slicing does not invoke undefined behavior. It involves refering to a
"base class subobject" within an object of the derived type. That subobject
will be used in the copy and therefore a copy initialized from that "slice"
is in a well-defined state as long as the object of the derived type is.
Whether that state is useful, however, is a different matter.


Best

Kai-Uwe Bux
 
G

Ganesh

First, the definition of polymorphism is not clear. Even a switch
statement in a C language is polymorphic (IMHO), but defined at compile
time. If you mean the "virtual function" mechanism to be the
polymorphism, the reason why it works with only pointers/references is
because it is the way it is implemented in C++ (IMHO). In Smalltalk
there are no pointers, but run time polymorphism still exists. C++
also has static polymorphism in the form of templates.
 
R

ravinderthakur

if that is the case then one more question :

I want to know why did't c++ committee devised some workaround to
allow the polymorphism through objects??? after all this could also be
benificial in some scenarios. why they altogehter banned this concept..
 
K

Karl Heinz Buchegger

if that is the case then one more question :

I want to know why did't c++ committee devised some workaround to
allow the polymorphism through objects??? after all this could also be
benificial in some scenarios.

I can't think of any.
Once you have an object, you already know its type. No
need for polymorphism any more.
 
L

LR

if that is the case then one more question :

I want to know why did't c++ committee devised some workaround to
allow the polymorphism through objects??? after all this could also be
benificial in some scenarios. why they altogehter banned this concept..

Just out of curiosity, I wonder how you'd like that to behave? Consider
this hypothetical:

(Not C++....)

..file "base.h"
class Base {
int b;
}
..end

..file "D1.h"
#include "base.h"
class D1 inherits from Base {
int d;
}
..end

..file "func.h"
int sizeOfBaseInFuncCpp();
..end

and...

..file "main.cpp"
#include "d1.h"
#include "func.h"
void main() { // remember, it's not c++... so void is ok ;)
Base t; // how much memory is used for t?
D1 d;

// what should this code do?
string s1=typeof(t); // (not c++, but intuitive?)
t = d;
string s2=typeof(t); //and this?

// What is the size of "Base" anyway?
int base_size_here = sizeof(t);
int base_size_elsewhere = sizeOfBaseInFuncCpp();
ASSERT(base_size_here == base_size_elsewhere);
}
..end

and in another part of the code forest compiled by someone on another
machine but using the same include files and compiler that we used for main.
..file "func.cpp"
#include "func.h"
#include "base.h"
// but NB that D1.h is not included here...
int sizeOfBaseInFuncCpp() {
Base t; // how much memory is used for t here?
return sizeof(t);
}
..end

Reminder: The above is _not_ C++.

Maybe better would be something like: I don't care for the way
polymorphism works in C++ because I want to do 'X'. Now please tell us
what 'X' is and perhaps your problem can be solved, or perhaps there is
already a solution.

LR
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

I want to know why did't c++ committee devised some workaround to
allow the polymorphism through objects??? after all this could also be
benificial in some scenarios. why they altogehter banned this concept..

Because of the no overhead rule. If you can imagine some system that allows
this type of polymorphism when the programmer wants but impose no cost at
all when not wanted, you can start writing a proposal. Then prepare for
convincing all people in the commitee that the proposal has enough benefits
to compensante for the cost to standarize, document and impose the cost of
implement it to all C++ compiler writers.
 
G

Ganesh

OK. Let us consider we allow such a thing in C++. How to implement it?
By the code of this kind:

(Assume A is an object, X and Y are classes).

if (typeid(A) == Y)
(X) A.func();
else if(typeid(A) == Y)
(Y) A.func();

This code is completely contradictory to run time polymorphism as this
restricts the polymorphism to compile time. If you add another class Z,
then you have to recompile everything. (IMHO)

Ganesh
 
M

Marc Mutz

LR wrote:
Maybe better would be something like:  I don't care for
the way polymorphism works in C++ because I want to do
'X'. Now please tell us what 'X' is and perhaps your
problem can be solved, or perhaps there is already a
solution.
<snip>

/me gets the impression that OP comes from Java, which has
exactly the syntax he asked for.

Marc
 
A

AndyRB

one counter argument kai:

the compiler can determine at the compile time if the class of the
object that is being created on the stack contains the virtaul function
and hence CAN put a pointer to vtable at the end of the object. after
all only a single pointer to the vtable needs to be put in to the
object. so the size of the objects of this class can be determinded at
the compile time.

so the question still remains:

why polymorphism dosn't work with objects in c++.

thanks
rt

You either have value semantics, by directly accessing the object, or
you have reference semantics, through a pointer or reference.

In the case of a pointer or reference, you have a static type which
maybe of a sub-object (base class) type and the dynamic type which is
always the most derived type. If the pointer is already of the most
derived type of the object, the static and dynamic type of the object
are the same. Calls to virtual functions will still be dispatched
dynamically at run-time (the compiler doesn't know if the static and
dynamic type are the same) but you won't end up calling a more derived
version of a function because you are already pointing to the most
derived object. So although polymorphism is enabled, in the above case,
it never comes into play.

In the case where you have value semantics, the static and the dynamic
type are always the same and the type will always be the most derived
object. The difference here to the scenario outlined above is that the
compiler knows that the static and dynamic types are the same and can
therefore work out the correct function to call at compile-time. Again
polymorphism doesn't come into play.

So, polymorphism can only *work* when the static and dynamic types are
different and this is never the case when using value semantics.
 
D

Dave Rahardja

hi experts,


just out of curosity why polymorphism is allowed to work only with
pointers and references to the objects and not with the objects itself.


what are the reasons behind forbidding this behavior.


is this restriction anyway related to the ABC.

thanks
rt

Hi RT,

It is done that way because in C++ only pointers and references allow the
declared type of the pointer or reference to differ from the actual type of
the object it's pointing at.

If you try to write a sample program that tries to do what you want to do,
you'll quickly see why it won't work without compromising type safety.

What's ABC?

-dr
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top