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

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-27 14:21:23

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);
>
> In Christ,
> Steven Watanabe
>

I didn't find any documentation on unordered_map in the boost documentation.
What's the reason for not sorting the map? It seems like it would be more
inefficient. STL Map is sorted for a reason.

BTW thank you for the design here. Can't believe I didn't think about this
:)