Re: [boost] [async] messages threads and networks

Subject: Re: [boost] [async] messages threads and networks
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-04-24 21:46:32

On Sat, Apr 24, 2010 at 2:28 PM, Scott Woods <scott_at_[hidden]> wrote:
> /* snip */

This pact library looks interesting from a cursory read of the 'about'
page.  Going to look through it and make comments.

On reading http://groups.google.com/group/pact-serialization/web/a-shortened-tour:

With this example:
"""
#include "pact/cursor.h"

    struct person
  {
      string name;
      int number;
  };

you will need the following transform functions (probably in the same
header file):

    inline void
    operator<<( cursor &parent, const person &p )
    {
        cursor &c = parent.output( 2 );
        c << p.name;
        c << p.number;
    }

    inline void
    operator>>( cursor &parent, person &p )
    {
        cursor &c = parent.input( 2 );
        c >> p.name;
        c >> p.number;
    }

Somewhere in your application, probably in person.cpp, you will also
need the following code fragments:

  #include "pact/type.h"

    COMPLEX_TYPE( person, "Organization.Product.Person" )
    {
        COMPLEX_MEMBER( "Name", name );
        COMPLEX_MEMBER( "Number", number );
    }
"""

If you were using boost, all of that could have been replaced with
something like this:
"""
#include <boost/fusion/include/adapt_struct.hpp>

struct person
  {
      string name;
      int number;
  };

BOOST_FUSION_ADAPT_STRUCT(
  person,
    (string,name)
    (int,number)
  )
// Probably something to register a name for it too, wrap it all up together
"""

And that is all in the header, no CPP usage needed.  Your system would
just register to handle the fusion types and you can suddenly
everything from structs, C static arrays, stl static containers
(including boost::array), and much more without needing to specialize
for any of them.

Also noticed that your enum registrations require a single CPP side
along with the header side, would it not be a lot easier to just
register in the header, like how fusion does it?  You could do
something like use Boost.MPL to save the enums and their values in a
type declaration instead, needing no operator<</>> overloads or
anything, and you handle the enum registration type.

Based on this sentence:
"""
During the "load" function Pact automatically detects the
non-existence of an expected file and instead of failing with an
error, it writes the current value of the object into the indicated
file. That's right; a function that appears to be an input function
also performs output.
"""
Would load not be better served by renaming to something consistent,
like load_or_create (bad name) or something better
(sync_to_filename?)?

Heh, nice names for the encodings:
"""
    *      Lean Text ­­– text, readable, portable
    *      Neat Bytes – binary, portable
    *      Byte Blast – binary, non-portable
    *      Word Markup – text, readable with appropriate tools,
portable, symbolic.
"""

The http://groups.google.com/group/pact-serialization/web/the-extended-journey
link does not exist.

Based on the description page, the Async I/O work and messaging looks
interesting.  Have not played with any actual source though, and do
not see and code examples page (maybe that extended journey missing
page?).  The type system could easily be vastly simplified with a few
Boost libraries.

Will look at it later when I get more time, looks interesting though,
but definitely need more information, speed, a lot more code examples,
etc...