Polymorphic types without virtual functions

Discussion in 'C++' started by Karel Miklav, Sep 3, 2005.

  1. Karel Miklav

    Karel Miklav Guest

    In lots of places in a programm I need to identify type of received
    messages, so I create them as virtual classes and use RTTI to find their
    type later. But these are simple messages, often without content, and I
    hate how I make their base class: by adding a dummy virtual function.

    Is there another way?

    --

    Regards,
    Karel Miklav
     
    Karel Miklav, Sep 3, 2005
    #1
    1. Advertising

  2. Karel Miklav

    benben Guest

    "Karel Miklav" <> wrote in message
    news:...
    > In lots of places in a programm I need to identify type of received
    > messages, so I create them as virtual classes and use RTTI to find their
    > type later. But these are simple messages, often without content, and I
    > hate how I make their base class: by adding a dummy virtual function.
    >
    > Is there another way?
    >
    > --
    >
    > Regards,
    > Karel Miklav


    I'm sure there are better ways other than relying on RTTI. However, before
    we know what a "message" means in your context and how it is supposed to be
    used there's not much we can help.

    Perhaps explain to us with more detail? Better still, post some code.

    Ben
     
    benben, Sep 3, 2005
    #2
    1. Advertising

  3. Karel Miklav wrote:
    > In lots of places in a programm I need to identify type of received
    > messages, so I create them as virtual classes and use RTTI to find their
    > type later. But these are simple messages, often without content, and I
    > hate how I make their base class: by adding a dummy virtual function.
    >
    > Is there another way?
    >


    There no way to make a class ploymorphic without using a virtual
    function. Normally the destructor is used for this purpose, not a dummy
    function.

    class polymorphic_case
    {
    public:
    virtual ~polymorphic_case() {}
    };


    Is there are better way than using RTTI? Well that depends.

    john
     
    John Harrison, Sep 3, 2005
    #3
  4. Karel Miklav

    Andre Kostur Guest

    Karel Miklav <> wrote in
    news::

    > In lots of places in a programm I need to identify type of received
    > messages, so I create them as virtual classes and use RTTI to find their
    > type later. But these are simple messages, often without content, and I
    > hate how I make their base class: by adding a dummy virtual function.
    >
    > Is there another way?


    Member variable enum determining which type they are?
     
    Andre Kostur, Sep 3, 2005
    #4
  5. Karel Miklav

    Karel Miklav Guest

    John Harrison wrote:
    > There no way to make a class ploymorphic without using a virtual
    > function. Normally the destructor is used for this purpose, not a dummy
    > function.
    >
    > class polymorphic_case
    > {
    > public:
    > virtual ~polymorphic_case() {}
    > };


    It'll have to do. Thanks.

    > Is there are better way than using RTTI? Well that depends.


    Shure, it's just the path of least resistance :)

    --

    Regards,
    Karel Miklav
     
    Karel Miklav, Sep 3, 2005
    #5
  6. On Sat, 03 Sep 2005 06:49:48 +0200, Karel Miklav
    <> wrote:

    >In lots of places in a programm I need to identify type of received
    >messages, so I create them as virtual classes and use RTTI to find their
    >type later. But these are simple messages, often without content, and I
    >hate how I make their base class: by adding a dummy virtual function.
    >
    >Is there another way?


    Using RTTI to implement polymorphic behavior is usually an indication of a
    design problem. Unless you're serializing/unserializing objects, RTTI is
    seldom necessary.

    Perhaps you can explain more about the problem you are trying to solve?
     
    Dave Rahardja, Sep 3, 2005
    #6
  7. Karel Miklav

    Karel Miklav Guest

    Dave Rahardja wrote:
    > Using RTTI to implement polymorphic behavior is usually an indication
    > of a design problem. Unless you're serializing/unserializing objects,
    > RTTI is seldom necessary.
    >
    > Perhaps you can explain more about the problem you are trying to
    > solve?


    I have a kind of ... game. This game gets messages about UI events
    from a platform dependant layer. Messages are various but simple, like:


    class some_display_event
    {
    public:

    virtual ~some_display_event() { };
    };

    class reconfigure_event : public some_display_event
    {
    public:

    int width;
    int height;

    reconfigure_event(int _width, int _height) :
    width(_width), height (_height) { };

    private:

    reconfigure_event();
    };

    class quit_event : public some_display_event { };

    ....


    Game knows how to use the UI, but the UI knows nothing about the game;
    of course they both speak the same message-passing language. The game
    then polls the UI from time to time:


    bool loop_endlessly = true;
    while(loop_endlessly)
    {
    ...

    some_display_event * event = display.check_events();
    if(event)
    {
    if(reconfigure_event * re =
    dynamic_cast<reconfigure_event *>(event))
    {
    reconfigure(re->width, re->height);
    delete re;
    }
    else if(quit_event * qe = dynamic_cast<quit_event *>(event))
    {
    delete qe;
    loop_endlessly = false;
    }
    else
    {
    delete event;
    throw 38122178;
    }
    }

    ...
    }


    Now this game can also draw nice things, consisting of nice and simple
    drawing primitives. These primitives are stored in containers, so they
    must be ... polymorphic. And here we go again!

    What do you say?

    --

    Regards,
    Karel Miklav
     
    Karel Miklav, Sep 3, 2005
    #7
  8. On Sat, 03 Sep 2005 23:57:14 +0200, Karel Miklav
    <> wrote:

    >I have a kind of ... game. This game gets messages about UI events
    >from a platform dependant layer. Messages are various but simple, like:
    >
    >
    >class some_display_event
    >{
    > public:
    >
    > virtual ~some_display_event() { };
    >};
    >
    >class reconfigure_event : public some_display_event
    >{
    > public:
    >
    > int width;
    > int height;
    >
    > reconfigure_event(int _width, int _height) :
    > width(_width), height (_height) { };
    >
    > private:
    >
    > reconfigure_event();
    >};
    >
    >class quit_event : public some_display_event { };
    >
    >...
    >


    Ah, the classical polymorphic event queue problem! The use of RTTI in this
    case is not only messy (as you have discovered), it is also _very_ expensive
    in the run-time domain, as each event will take on average N/2 dynamic_cast's
    to determine what event it actually is (where N is the total number of event
    classes). If you receive several thousand messages per second (typical for a
    GUI), the lookup overhead will be significant.

    I suspect what you want is an event _interface_:

    class some_display_event
    {
    public:
    virtual void do() = 0; // pure virtual
    };

    and each event will implement do() in its own intelligent way:

    class reconfigure_event: public some_display_event
    {
    public:
    int width;
    int height;

    reconfigure_event(int width, int height);
    virtual void do();
    };

    void reconfigure_event::do()
    {
    renconfigure(width, height);
    }

    and your event loop will look like:

    while(loop_endlessly)
    {
    /* ... */

    some_display_event* event = display.check_events();
    event->do();

    /* ... */
    }

    Now the overhead for processing each event is constant, i.e. one virtual
    function address lookup.

    -dr
     
    Dave Rahardja, Sep 5, 2005
    #8
  9. Karel Miklav

    Karel Miklav Guest

    Dave Rahardja wrote:
    > Ah, the classical polymorphic event queue problem! The use of RTTI in
    > this case is not only messy (as you have discovered), it is also
    > _very_ expensive in the run-time domain, as each event will take on
    > average N/2 dynamic_cast's to determine what event it actually is
    > (where N is the total number of event classes). If you receive
    > several thousand messages per second (typical for a GUI), the lookup
    > overhead will be significant.
    >
    > I suspect what you want is an event _interface_:
    >
    > class some_display_event
    > {
    > public:
    > virtual void do() = 0; // pure virtual
    > };


    Dave, thanks very much. In the mean time I've come to the same solution
    for my other problem (graphic primitive list) and you won't believe
    this - my interface has the same do() function :)

    I have afterthoughts in this case as I don't want the user interface to
    know how events are implemented but it might work if I keep the header
    clean.

    --

    Regards,
    Karel Miklav
     
    Karel Miklav, Sep 6, 2005
    #9
  10. Karel Miklav

    red floyd Guest

    Karel Miklav wrote:

    >
    > I have afterthoughts in this case as I don't want the user interface to
    > know how events are implemented but it might work if I keep the header
    > clean.
    >


    Look into the Pimpl idiom as well. This is pretty much a wrapper around
    a pointer, whose implementation details you want hidden.
     
    red floyd, Sep 6, 2005
    #10
    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. Dave
    Replies:
    9
    Views:
    381
    Victor Bazarov
    Dec 26, 2003
  2. Aryeh M. Friedman
    Replies:
    2
    Views:
    1,107
    Ron Natalie
    Feb 21, 2005
  3. pmatos
    Replies:
    5
    Views:
    345
    Marcin Kalicinski
    Mar 11, 2005
  4. pmatos
    Replies:
    3
    Views:
    355
    Victor Bazarov
    Mar 24, 2005
  5. John Goche
    Replies:
    10
    Views:
    757
    Marcus Kwok
    Dec 8, 2006
Loading...

Share This Page