Polymorphic types without virtual functions

K

Karel Miklav

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?
 
B

benben

Karel Miklav said:
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?

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
 
J

John Harrison

Karel said:
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
 
A

Andre Kostur

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?
 
K

Karel Miklav

John said:
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 :)
 
D

Dave Rahardja

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?
 
K

Karel Miklav

Dave said:
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?
 
D

Dave Rahardja

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
 
K

Karel Miklav

Dave said:
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.
 
R

red floyd

Karel said:
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.
 

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

Staff online

Members online

Forum statistics

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

Latest Threads

Top