On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
#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".
Fusion is completely compile-time in how it can assign 'views' to types, but your type registration is independent, hence why making your own macro that handle that and the fusion view adaptation would be best, it would negate the need for your operator>>/<< functions is all it is, would vastly simplify code and reduce chance of errors. On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
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?
See above response, you could easily make the values saved in the types at compile-time, and still use your type system to determine what is what, would provide a speed-boost at run-time while simplifying code and reducing the chance of errors. On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
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.
I was logged in, unsure why it shows 404 for the most recent version, but I was able to view the second to most recent easily as shown by my next sent email after that first one. On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
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.
Once I was able to view the missing page (at least the older version of it) it clarified many things and became sufficient in my opinion, just need to make sure links work. :) On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
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.
Only had a request for documentation because that massive extended tutorial page was missing, once I was able to view it, it all worked much better. On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott@wdesignnz.co.nz> wrote:
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?
I was not asking if it was slow, just asking if you had speed reports and comparisons, through-put tests for network (perhaps in comparison to other libs, Raknet for example, or Erlang too for massage passing tests?), etc... Cannot try to compile it right now, my main computer is down, and Visual Studio does not work on PocketPC/Arm.