Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-07-28 15:53:40
On Thu, Jul 28, 2011 at 2:49 PM, Antony Polukhin <antoshkka_at_[hidden]>wrote:
> 2011/7/28 Daniel Larimer <dlarimer_at_[hidden]>:
> > I have just recently completed my first alpha release of a generic RPC
> > library designed to support different protocols (JSON, XML, Protocol
> > Buffers) and different transports (UDP, TCP, HTTP) in a generic manner.
> Sounds great!
> > Lastly all of this builds on top of my Boost.CMT (Collaborative
> > Multi-Tasking Library) which seems to be along the same lines as Oliver's
> > Boost.Strand library, but with a simpler interface. It is built on top
> > Boost.Context. This allows the RPC to be asynchronous, thread-safe, and
> > free of nasty completion handlers.
> You don`t use asio, is you code portable to other operating systems?
> Can it be tuned, to use asio/libev?
It uses Boost.ASIO for all networking. I just wrap Boost.ASIO async calls
Boost.CMT 'coroutine' handlers such that an async call becomes a
of a callback. This way there is no need to worry about threading issues.
> > I have documentation of all three libraries posted here.
> > http://bytemaster.github.com/dev/modules.html
> I took a quick glance. Looks like "alpha release", but it is possible
> to understand the idea.
> This looks like not a safe approach:
> void operator()( Member Class::*p, const char* name )
> You serialize no info about function parameters.
Depends upon which visitor you are using. If you are visiting all of the
functors on a boost::reflect::vtable as used by
boost::reflect::any_ptr<Interface> then Member is a
boost::reflect::mirror_member<> specialization (a functor) and therefore
Member::fused_params -> boost::fusion::vector<paramtypes> or
Member::traits -> boost::function_traits.
29 shows how to print out the function signature for the member.
If you are using boost::reflector<T>::visit( visitor ) and you expected your
visitor to handle member functors then your visitor would need
specializations for each different
number of parameters (or veridic templates).
In practice I find that for interfaces I am using the vtable of functors in
any_ptr<Interface> and for data types (structures) that I use as parameters
I am only reflecting public members and not functors. For an example of
how reflection serializes structs see:
> I`m interested, but now I have no projects were it is possible to use
> your library.
> Best regards,
> Antony Polukhin
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk