Re: using compilers' internal virtual table information

Discussion in 'C++' started by Dombo, Dec 30, 2010.

  1. Dombo

    Dombo Guest

    Op 30-Dec-10 16:15, Hicham Mouline schreef:
    > hello,
    >
    > 1) baseptr->f1()
    > When a base class has virtual member functions, and a reference or a pointer
    > to that base instance is passed around the code, client code can call those
    > functions and the runtime will correctly call the appropriate function
    > applicable to the actual type of the instance passed around.
    >
    > 2) widget* create_widget( const base& )
    > Now there are cases where the client code receives such as base pointer or
    > reference, and requires a polymorphic behaviour similar to the above,
    > however the client code cannot/should not change the class definition. An
    > example I have is separate application code from GUI code.
    > 1 solution is to have the client code aware of all possible most derived
    > types from the base class, in some sort of type list, try to dynamic_cast<>
    > the received base pointer/reference to each most derived type until success,
    > and then do whatever needs doing.
    > This reduces the dependencies. The base and derived classes know nothing
    > about the existence of a GUI.


    It is not entirely clear to me why you cannot use virtual functions in
    this case, or why you would require down casting. The approach you
    describe appears to be rather maintenance intensive and error prone.

    > This dynamic cast trial appears similar to what the compilers must do
    > internally, though it's possibly slower.


    A typical C++ compiler won't use a dynamic_cast<> style trail-and-error
    approach (which would be terribly inefficient) to achieve polymorphic
    behavior. Instead C++ compilers often uses vtables to implement
    polymorphic behavior. These compilers generate a vtable for each class
    with virtual functions. The vtable contains the addresses to the actual
    function. Each instance of a class with virtual functions will have a
    hidden pointer to the vtable of that class. This way the processor can
    directly jump to the appropriate function via the vtable at runtime.

    Note that the C++ standard does not require vtables and that your
    compiler may use a different approach.

    > Is there a way to use the compiler's internal methods/information to realize
    > the above?


    dynamic_cast<> is normally rarely needed. If you do need it all over the
    place than it time to seriously reconsider your design. However in those
    rare cases the caller must do different things depending on the actual
    type, downcasting using dynamic_cast<> would be your best option. (btw.
    don't bother with typeid()).
    Dombo, Dec 30, 2010
    #1
    1. Advertising

  2. "Dombo" <> wrote in message
    news:4d1cb426$0$30709$...
    > Op 30-Dec-10 16:15, Hicham Mouline schreef:
    >> hello,
    >>
    >> 1) baseptr->f1()
    >> When a base class has virtual member functions, and a reference or a
    >> pointer
    >> to that base instance is passed around the code, client code can call
    >> those
    >> functions and the runtime will correctly call the appropriate function
    >> applicable to the actual type of the instance passed around.
    >>
    >> 2) widget* create_widget( const base& )
    >> Now there are cases where the client code receives such as base pointer
    >> or
    >> reference, and requires a polymorphic behaviour similar to the above,
    >> however the client code cannot/should not change the class definition. An
    >> example I have is separate application code from GUI code.
    >> 1 solution is to have the client code aware of all possible most derived
    >> types from the base class, in some sort of type list, try to
    >> dynamic_cast<>
    >> the received base pointer/reference to each most derived type until
    >> success,
    >> and then do whatever needs doing.
    >> This reduces the dependencies. The base and derived classes know nothing
    >> about the existence of a GUI.

    >
    > It is not entirely clear to me why you cannot use virtual functions in
    > this case, or why you would require down casting. The approach you
    > describe appears to be rather maintenance intensive and error prone.
    >
    >> This dynamic cast trial appears similar to what the compilers must do
    >> internally, though it's possibly slower.

    >
    > A typical C++ compiler won't use a dynamic_cast<> style trail-and-error
    > approach (which would be terribly inefficient) to achieve polymorphic
    > behavior. Instead C++ compilers often uses vtables to implement
    > polymorphic behavior. These compilers generate a vtable for each class
    > with virtual functions. The vtable contains the addresses to the actual
    > function. Each instance of a class with virtual functions will have a
    > hidden pointer to the vtable of that class. This way the processor can
    > directly jump to the appropriate function via the vtable at runtime.
    >
    > Note that the C++ standard does not require vtables and that your compiler
    > may use a different approach.
    >
    >> Is there a way to use the compiler's internal methods/information to
    >> realize
    >> the above?

    >
    > dynamic_cast<> is normally rarely needed. If you do need it all over the
    > place than it time to seriously reconsider your design. However in those
    > rare cases the caller must do different things depending on the actual
    > type, downcasting using dynamic_cast<> would be your best option. (btw.
    > don't bother with typeid()).


    The initial class hiearchy exists separately. At a later stage, GUI
    functionality is added. That functionality depends on the actual type of the
    class from the initial hierarchy.
    I can't/won't touch the initial class hiearchy.
    90% of the code only depends on the base class refereences. Some remaining
    10% of the code (in the gui) only needs to know the real types.
    That forces me to do this down_cast affair.

    What's a better way to address the concern of those 10% of the code that
    receives the base reference to determine which actual type it is dealing
    with?

    regards,
    Hicham Mouline, Dec 31, 2010
    #2
    1. Advertising

  3. On 31 Dez. 2010, Hicham Mouline wrote:
    > The initial class hiearchy exists separately. At a later stage, GUI
    > functionality is added. That functionality depends on the actual type of the
    > class from the initial hierarchy.
    > I can't/won't touch the initial class hiearchy.
    > 90% of the code only depends on the base class refereences. Some remaining
    > 10% of the code (in the gui) only needs to know the real types.
    > That forces me to do this down_cast affair.
    >
    > What's a better way to address the concern of those 10% of the code that
    > receives the base reference to determine which actual type it is dealing
    > with?


    If I could not change the original class hierarchy (because its some
    third party library), I'd introduce a second class hierarchy that adds
    the relevant behaviour to the already existing classes. This second
    hierarchy can be added by the help of templates so that you don't have
    to add too code manually (if the original hierarchy is quite large).

    Regards,
    Stuart
    Stuart Redmann, Jan 3, 2011
    #3
    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. z. f.
    Replies:
    0
    Views:
    675
    z. f.
    Feb 3, 2005
  2. Alec S.
    Replies:
    14
    Views:
    589
    Alec S.
    Feb 4, 2005
  3. manohar
    Replies:
    6
    Views:
    431
  4. qazmlp
    Replies:
    19
    Views:
    789
    Daniel T.
    Feb 4, 2004
  5. geletine

    commercial c compilers vs free c compilers

    geletine, Jul 2, 2006, in forum: C Programming
    Replies:
    33
    Views:
    1,313
Loading...

Share This Page