AMDG

Robert Dailey wrote:
> It's sad to find out about the restrictions of the templates, but I
> can understand. I just finally began to understand your design
> proposal and had already planned on using it :(

Well, you could use MPL list which does not have a fixed upper limit,
but you may just run into compiler limits instead of MPL limits.

> Your unordered_map seems redundant, in that you have packet ID's to
> different function objects with exactly the same signature. I guess
> this is so we only dispatch packets to subscribers interested in that
> specific packet. Could you emphasize a little more on what you mean by
> "store references to the individual signals"? The downcasting logic
> could be done via a 'get' method.... packet::get<WalkPacket>(), but
> this is pretty much exactly like doing static_cast<>() directly. get()
> would have the potential of returning a NULL auto_ptr if the type
> specified by the get<>() does not represent the concrete type of the
> packet.

typedef boost::unordered_map<PacketID, boost::function<void(Packet
const&)> > dispatcher;

template<class T>
struct StaticCaster {
StaticCaster(boost::signal<void(T const&)> &signal) : signal(signal) {}
boost::signal<void(T const&)> &signal;
void operator()(Packet const& packet) const {
signal(static_cast<T const&>(packet));
}
};

// load the table.
// you will probably need a second map to allow functions to
// be registered with the signals.

boost::signal<void(WalkPacket const&)> walkPacketSignal;
dispatcher.insert(make_pair(PID_WALKPACKET,
staticCaster<WalkPacket>(walkPacketSignal)));

// dispatching

dispatcher[id](packet);

In Christ,
Steven Watanabe