On Sat, Apr 24, 2010 at 2:28 PM, Scott Woods <scott@wdesignnz.co.nz> 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...