Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Polymorphic types without virtual functions

Reply
Thread Tools

Polymorphic types without virtual functions

 
 
Karel Miklav
Guest
Posts: n/a
 
      09-03-2005
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
 
Reply With Quote
 
 
 
 
benben
Guest
Posts: n/a
 
      09-03-2005

"Karel Miklav" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      09-03-2005
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
 
Reply With Quote
 
Andre Kostur
Guest
Posts: n/a
 
      09-03-2005
Karel Miklav <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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?
 
Reply With Quote
 
Karel Miklav
Guest
Posts: n/a
 
      09-03-2005
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
 
Reply With Quote
 
Dave Rahardja
Guest
Posts: n/a
 
      09-03-2005
On Sat, 03 Sep 2005 06:49:48 +0200, Karel Miklav
<(E-Mail Removed)> 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?
 
Reply With Quote
 
Karel Miklav
Guest
Posts: n/a
 
      09-03-2005
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
 
Reply With Quote
 
Dave Rahardja
Guest
Posts: n/a
 
      09-05-2005
On Sat, 03 Sep 2005 23:57:14 +0200, Karel Miklav
<(E-Mail Removed)> 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
 
Reply With Quote
 
Karel Miklav
Guest
Posts: n/a
 
      09-06-2005
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
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      09-06-2005
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
private virtual functions and pure virtual functions with bodies John Goche C++ 10 12-08-2006 04:00 PM
Problem with results of overloading << for polymorphic types... pmatos C++ 3 03-24-2005 01:50 AM
Polymorphic types and a lot of confusion.... pmatos C++ 5 03-11-2005 01:06 AM
polymorphic return types in virtual functions Aryeh M. Friedman C++ 2 02-21-2005 01:53 PM
Polymorphic behavior without virtual functions Dave C++ 9 12-26-2003 02:08 AM



Advertisments