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

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-27 09:38:12

On Wed, Mar 26, 2008 at 9:20 PM, Steven Watanabe <watanabesj_at_[hidden]>
wrote:

> AMDG
>
> Robert Dailey wrote:
> > After investigating this a little more (plus from the answers you
> > provided above) I think I fully understand the problem. My only
> > concern at this point is compile time, as you pointed out. For 100
> > packet types, do you think compile time would be noticeably affected
> > (assuming that all of the boost includes are in a precompiled header
> > file)? How about for 1000 packet types?
>
> 1000 packet types is unfeasible because mpl uses the preprocessor
> lib to generate the vector specializations--Boost.Preprecessor has
> a hard limit of 256 and some preprocessors give out even before that
> point.
>
> It turns out that MPL does not actually permit the upper limit
> of 50 to be configured.  This a little annoying especially because
> all the framework needed is already in place.  I had to use a private
> header to generate vector100 for a test (It took 43 seconds to
> compile, BTW)
>
> If you have so many types of packets, you are probably better off
> using runtime dispatching.
>
> typedef boost::unordered_map<PacketID, boost::function<void(Packet
> const&)> > dispatcher;
>
> and then store references to the individual signals along with the
> downcasting logic
> in the boost::function<>s
>
> In Christ,
> Steven Watanabe
>

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 :(

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.