polymorphism

Discussion in 'C++' started by ravinderthakur@gmail.com, Aug 24, 2005.

  1. Guest

    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
     
    , Aug 24, 2005
    #1
    1. Advertising

  2. Kai-Uwe Bux Guest

    wrote:

    > 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
     
    Kai-Uwe Bux, Aug 24, 2005
    #2
    1. Advertising

  3. Srini Guest

    > 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
     
    Srini, Aug 24, 2005
    #3
  4. Guest

    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
     
    , Aug 24, 2005
    #4
  5. Guest

    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
     
    , Aug 24, 2005
    #5
  6. Srini Guest

    > 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
     
    Srini, Aug 24, 2005
    #6
  7. Kai-Uwe Bux Guest

    wrote:

    > 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
     
    Kai-Uwe Bux, Aug 24, 2005
    #7
  8. Guest

    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
     
    , Aug 24, 2005
    #8
  9. Kai-Uwe Bux Guest

    wrote:

    > 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
     
    Kai-Uwe Bux, Aug 24, 2005
    #9
  10. Greg Guest

    wrote:
    > 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
     
    Greg, Aug 24, 2005
    #10
  11. Kai-Uwe Bux Guest

    Greg wrote:

    >
    > 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
     
    Kai-Uwe Bux, Aug 24, 2005
    #11
  12. Ganesh Guest

    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.
     
    Ganesh, Aug 25, 2005
    #12
  13. Guest

    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..
     
    , Aug 25, 2005
    #13
  14. wrote:
    >
    > 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.

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Aug 25, 2005
    #14
  15. LR Guest

    wrote:

    > 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
     
    LR, Aug 25, 2005
    #15
  16. wrote:

    > 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.

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Aug 25, 2005
    #16
  17. Ganesh Guest

    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
     
    Ganesh, Aug 25, 2005
    #17
  18. Marc Mutz Guest

    LR wrote:
    <snip>
    > 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
     
    Marc Mutz, Aug 25, 2005
    #18
  19. AndyRB Guest

    wrote:
    > 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.
     
    AndyRB, Aug 25, 2005
    #19
  20. On 24 Aug 2005 00:45:42 -0700, wrote:

    >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
     
    Dave Rahardja, Aug 27, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Lawrence

    Polymorphism in GridView (ASP.Net 2.0)

    Kevin Lawrence, Feb 16, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    861
    Kevin Lawrence
    Feb 16, 2006
  2. Sony Antony

    Polymorphism in xml ??

    Sony Antony, Aug 26, 2003, in forum: Java
    Replies:
    0
    Views:
    572
    Sony Antony
    Aug 26, 2003
  3. Osaman
    Replies:
    2
    Views:
    458
    John C. Bollinger
    Jan 5, 2004
  4. Tony Morris

    polymorphism

    Tony Morris, Mar 7, 2004, in forum: Java
    Replies:
    1
    Views:
    739
    sonali
    Mar 7, 2004
  5. Krivenok Dmitry
    Replies:
    13
    Views:
    1,472
    Axter
    Jun 1, 2006
Loading...

Share This Page