Dynamically appending custom data to an object

[Luc Tremblay]

Given the typical following code:

void Listener::Handl eEvent(const Event& event)
{
// handling code
}

In a "clean" fashion, how is it possible to add custom data (to be
subsequently accessed) to the Event instance? By custom data i mean
practically anything, from a class to a single int. Particularly to my case,
it would be assumed that such data would be appropriately destroyed as the
Event is consumed/destroyed.

I have considered several options but still can't find one that satisfies
the "clean" requisite. One implies keeping a void* "userData" in the Event
class, and using setData<T>/getData<T> template methods to access and
automagically cast the data to the proper type, with type safety checks in
debug. Problems arise if I want the Event class to handle the destruction of
the custom data because internally to Event, the custom data's type is
unknown. Again particularly to my case, I could use a memory pool for the
custom data, write the custom data to it using placement new and then clean
the pool after each frame as all events are considered "consumed" between
event iterations. Potential problems arise if classes are used as custom
data, since cleaning the memory pool wouldn't call the destructors of the
custom data.

I would guess Boost::any would also be a solution, but we are trying to
avoid using it in our project.

Subclassing the Event class and adding the custom data as members, and then
downcasting to the proper type, is probably also a solution. I am thinking
it is possibly the only interesting solution (as it is very common), but I
hope to think someone thought of an elegant alternative. I think it is
likely that there is a templated solution, yet i can't figure it out.

It has to be kept in mind that the Event class, in my case, would
potentially be part of an external library, so using a union member of all
possible custom data types isn't a viable solution (not to say it is quite
ugly...)

Regards,

Luc Tremblay

[John Harrison]

On Mon, 5 Jul 2004 18:00:03 -0300, Luc Tremblay <an*******@symp atico.ca>
wrote:

Given the typical following code:

void Listener::Handl eEvent(const Event& event)
{
// handling code
}

In a "clean" fashion, how is it possible to add custom data (to be
subsequently accessed) to the Event instance? By custom data i mean
practically anything, from a class to a single int. Particularly to my
case,
it would be assumed that such data would be appropriately destroyed as
the
Event is consumed/destroyed.

[snip]
I
hope to think someone thought of an elegant alternative. I think it is
likely that there is a templated solution, yet i can't figure it out.

Assuming HandleEvent is not virtual then the following might work

template <class T>
void Listener::Handl eEvent(const Event<T>& event)
{
// handling code
}

with Event defined like this

template <class T>
class Event
{
// standard event stuff
...
// user data
T user;
};

Something to think about anyway.

john

[Raghupathy]

How about having an interface and call it as ICustData, with a virtual
destructor.

Any class which wants to be appendable will need to implement this
interface.
Your host class will then have a member ICustData* m_pCustData, with
get/set methods to access the ICustData member. The client can then
use dynamic_cast to get the actual pointer that he needs.

And when the host class goes out of scope, just call delete on
m_pCustData. Since the destructor is virtual, the correct destructor
will be called.

It's a pretty straight forward solution, but is this what you are
looking for? And do you find it intutive?

"Luc Tremblay" <an*******@symp atico.ca> wrote in message news:<z9******* *************@n ews20.bellgloba l.com>...

Given the typical following code:

void Listener::Handl eEvent(const Event& event)
{
// handling code
}

In a "clean" fashion, how is it possible to add custom data (to be
subsequently accessed) to the Event instance? By custom data i mean
practically anything, from a class to a single int. Particularly to my case,
it would be assumed that such data would be appropriately destroyed as the
Event is consumed/destroyed.

I have considered several options but still can't find one that satisfies
the "clean" requisite. One implies keeping a void* "userData" in the Event
class, and using setData<T>/getData<T> template methods to access and
automagically cast the data to the proper type, with type safety checks in
debug. Problems arise if I want the Event class to handle the destruction of
the custom data because internally to Event, the custom data's type is
unknown. Again particularly to my case, I could use a memory pool for the
custom data, write the custom data to it using placement new and then clean
the pool after each frame as all events are considered "consumed" between
event iterations. Potential problems arise if classes are used as custom
data, since cleaning the memory pool wouldn't call the destructors of the
custom data.

I would guess Boost::any would also be a solution, but we are trying to
avoid using it in our project.

Subclassing the Event class and adding the custom data as members, and then
downcasting to the proper type, is probably also a solution. I am thinking
it is possibly the only interesting solution (as it is very common), but I
hope to think someone thought of an elegant alternative. I think it is
likely that there is a templated solution, yet i can't figure it out.

It has to be kept in mind that the Event class, in my case, would
potentially be part of an external library, so using a union member of all
possible custom data types isn't a viable solution (not to say it is quite
ugly...)

Regards,

Luc Tremblay

[Luc Tremblay]

"John Harrison" wrote

On Mon, 5 Jul 2004 18:00:03 -0300, Luc Tremblay
wrote:

Assuming HandleEvent is not virtual then the following might work

Unfortunately, in my case, it indeed needs to be virtual.

[Luc Tremblay]

"Raghupathy " wrote :

How about having an interface and call it as ICustData, with a virtual
destructor.

Any class which wants to be appendable will need to implement this
interface.
Your host class will then have a member ICustData* m_pCustData, with
get/set methods to access the ICustData member. The client can then
use dynamic_cast to get the actual pointer that he needs.

And when the host class goes out of scope, just call delete on
m_pCustData. Since the destructor is virtual, the correct destructor
will be called.

It's a pretty straight forward solution, but is this what you are
looking for? And do you find it intutive?

Unfortunately your solution rules out base types, which is unacceptable in
my case.

[Luc Tremblay]

Luc Tremblay wrote :

In a "clean" fashion, how is it possible to add custom data (to be
subsequently accessed) to the Event instance? By custom data i mean
practically anything, from a class to a single int. Particularly to my case, it would be assumed that such data would be appropriately destroyed as the
Event is consumed/destroyed.

I should correct myself. I do not mean dynamically as in "during process
itself"; a pre-definition of the data type to use for each Event is
possible, considering Events are uniquely defined by their UId. This leads
me to think that a solution would be a templated factory that maps Event Ids
to data types.

[Alf P. Steinbach]

* Luc Tremblay:

Given the typical following code:

void Listener::Handl eEvent(const Event& event)
{
// handling code
}

In a "clean" fashion, how is it possible to add custom data (to be
subsequently accessed) to the Event instance? By custom data i mean
practically anything, from a class to a single int. Particularly to my case,
it would be assumed that such data would be appropriately destroyed as the
Event is consumed/destroyed.

You need downcasting, but that downcasting should be centralized, not
forced upon each event consumer.

To centralize the downcasting use the visitor pattern.

// General event definitions.

class Event;
class IEventConsumer
{
protected:
virtual onEvent( Event const& anEvent ) {};
};
class Event
{
public:
virtual void visit( IEventConsumer& aConsumer )
{
aConsumer.onEve nt( *this );
};
};
// A particular event with custom data.

class CustomData;
class CustomEvent;

class ICustomEventCon sumer: public IEventConsumer
{
protected:
virtual onCustomEvent( CustomEvent const& anEvent ) {};
};

class CustomEvent: public Event
{
public:
typedef Event Base;

virtual void visit( IEventConsumer& aConsumer )
{
ICustomEventCon sumer* pi = dynamic_cast<IC ustomEventConsu mer*>( &aConsumer );
if( pi != NULL )
{
pi->onCustomEven t( *this );
}
else
{
Base::visit( aConsumer );
}
}

CustomData const& data() const { ... }
};
// A client

class Client: protected ICustomEventCon sumer
{
protected:
virtual void onCustomEvent( CustomEvent const& anEvent )
{
CustomData const& = anEvent.data(); ¨

// Whatever.
}
};
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Denis Remezov]

Luc Tremblay wrote:

"John Harrison" wrote

On Mon, 5 Jul 2004 18:00:03 -0300, Luc Tremblay
wrote:

Assuming HandleEvent is not virtual then the following might work

Unfortunately, in my case, it indeed needs to be virtual.

Then you could rearrange it like this:

class EventBase {
// standard event stuff
};

void Listener::Handl eEvent(const EventBase& event)
{
// handling code
}

template <class T>
class Event : public EventBase {
// user data
T user;
};

Since Listener::Handl eEvent() seems pretty much fixed in that
that it receives a reference of some base type of event, the
real question is how you do the dispatching based on the
dynamic type of an event. I think the solution may depend
a lot on the typical kind of the user data T and the way you
have to handle it.

For the simplest case, if handling of all possible types of
the user data could be provided in a uniform way:

class Action {
public:
template <typename T>
void handle(T const& v);
};

then declaring the following function in EventBase
virtual void handleUserData( Action& pa) const = 0;

and implementing it in Event<T> as
void handleUserData( Action& a) const {a.handle(user) ;}

would solve the most of the problem.

Denis