On Wed, Mar 26, 2008 at 9:20 PM, Steven Watanabe <watanabesj@gmail.com> 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.