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

Subject: Re: [boost] [async] messages threads and networks
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-04-25 01:11:39

On Sat, Apr 24, 2010 at 9:31 PM, Scott Woods <scott_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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.