Hi,
#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.
This basically looks appealing. I have one question though. I jumped through a few hoops so that registration does not need to mention the type - it is auto-generated from the member name. I would be happy to leverage the work of Fusion but sad to lose the correctness guarantee offered by auto-generating the type. Can Fusion offer that as well? As the types get more complicated the chances of a registration error (i.e. an incorrectly associated type ) move from "possible" to "expected".
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.
Again, this sounds good. From the words you use it sounds like the Fusion registrations are a compile-time facility? Pact registrations create information in a runtime database. That database is searched/iterated by parts of the library (such as the one that generates an XML encoding), based on a type id. There is no compile-time type information available to that part of the library. The type database also needs to be something that can be sent around a network. Are MPL/Fusion-based solutions still a good direction given these requirements?
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?)?
Understand your point. The full name is of course "pact::load". Being a verb in its own namespace I was hoping it could define its own specific meaning. Happy to concede to a majority opinion that I was misdirected.
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. """
Well - a bit cutesy but alternatives were unremarkable. Check the last section of the "extended journey" (Why the silly encoding names) for an attempt at absolution.
The http://groups.google.com/group/pact-serialization/web/the-extended-journey link does not exist.
Very unfortunate. I have had a few problems with links in Google Groups. They seem to be a symptom of not being signed in, i.e. do you have a Google identity? This is the subject of the first entry in the group discussions. Quite why it should make any difference is beyond me. There is nothing in any of the GG documentation that suggests non-signed-in (unsigned?) viewing gets a lower class of service. I did discover a crude fix so I will look at this again.
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,
All the documentation you have seen has been written specifically to present the library to parties such as Boost (i.e. you). From initial responses I'm guessing that the time and energy consumed by that effort is unlikely to result in anything. Thats a lot of effort that could have been directed into other development. Apologies for the small rant but requests for documentation are endless. I deliberately compiled a complete list of supporting documents and then chopped it down to the set achievable writing at 2am to avoid family obligations. I would love to finish the full set but there must be a proper opportunity. More speed? Always interested in making software faster but where is it slow? I also enjoy code examples but have you downloaded the samples solution yet? You are asking for more code beyond that provided in the samples? Thanks, Scott