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

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