Boost logo

Boost Users :

From: Kevin Scarr (kscarr_at_[hidden])
Date: 2008-03-26 03:03:12


Steven Watanabe wrote:
> You might also look into replacing Packet with boost::variant.

I would second this. If you use:

typedef boost::variant<WalkPacket,CharPacket,etc> Packet;

You might also consider using pointers in your Packet type, or even
shared_ptr<WalkPacket>, etc, but that is a detail which depends on how
the rest of your application is built. I use pointer-like types because
I am very aware of making copies of my potentially-large and numerous
packets.

In this situation, all of your messaging infrastructure that deals with
packets passes around instances of the variant type.

As you have described, your clients have a mechanism where they can
register using wrapper functions around the signals library to receive
notification on the arrival of specific packet types - one signal for
each packet type.

When it comes time to distribute your packet, you can make use of the
boost::variant visitor feature, which allows you to select operations
based on the actual type of the data in your variant instance. In your
case it might look something like this:

// Your packet type
typedef boost::variant<WalkPacket,ChatPacket,etc> Packet;

// Your signals...
boost::signal<void (WalkerPacket)> distributeWalkerPacket;
boost::signal<void (ChatPacket)> distributeChatPacket;

// Helper class for apply_visitor

class doDistributePacket : public static_visitor<>
{
public:

   void operator() ( WalkPacket p ) const
   {
     distributeWalkPacket( p );
   }

   void operator() ( ChatPacket p ) const
   {
     distributeChatPacket( p );
   }

// and so on ...
};

// Free function to drive this above.
void DistributePacket( Packet p )
{
   apply_visitor( doDistributePacket(), p );
}

I like boost::variant because it tends to bring all the type-dependent
code together and makes it easy to encapsulate type based decisions.

Kevin


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net