Re: [Boost-users] Need boost's help with poor design

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-28 12:41:42

On Thu, Mar 27, 2008 at 11:30 AM, Steven Watanabe <watanabesj_at_[hidden]>
wrote:

> 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);

Subscription doesn't seem as simple as you proposed. I looked into possible
designs for subscribing to the signals and nothing is working out. There's
no way to generate a second map to provide slot connections, since the
signal object is actually owned by the first map, and thus the two cannot
share them. Secondly, the slots (given the design above) each have a
different signature for each packet, which further complicates things.

Any suggestions? I'm having trouble thinking outside the box...