On Fri, Mar 28, 2008 at 4:10 PM, Asif Lodhi <asif.lodhi@gmail.com> wrote:
Hi Robert,

On 3/28/08, Robert Dailey <rcdailey@gmail.com> wrote:
> On Thu, Mar 27, 2008 at 11:30 AM, Steven Watanabe <watanabesj@gmail.com>
> wrote:
>X .............................................................................................................
> Any suggestions? I'm having trouble thinking outside the box...

Don't you think that _downcasting_ the return value of your factory
method defeats the whole point of using the factory method in the
first place? It looks like that you need to use "parameterized"
factories so that when you read the packet-id, your factory method
instantiates an object of the correct packet class after reading the
packet-id. As regards to sending the packet, it looks like you need to
have some kind of a "dispatcher" class in place which should have a
send method taking a reference of your base packet class as a
parameter. Don't you think it would solve the downcasting problem? If
you do have some functionality in your the child packet classes that
is forcing you to downcast then may be you should rethink your
object-model design.

Don't you think your problem is a case for re-design instead of using Boost?

Just my two cents.

The problem is that the type of the packet is not known until runtime. This makes it very difficult to make things "type safe" at compile time. What Steven has presented is about as type-safe as you can make it. However, the system does not prevent you from mismatching ID's with actual packet types, but that's just a natural problem with data driven designs. Right now there is no possible way to have a factory that returns the original type of the packet, since what is being passed in (the ID) is not known at compile time, as I've already stated.

With all of Steven's excellent help and some thought process of my own I am unable to find a better design than the one I have. It's not fair to compare runtime-designs with compile-time designs.

Thanks for your input.