Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Oleg Labutin (ol.labutin_at_[hidden])
Date: 2014-12-08 15:46:27
No any questions, currenlty I'd like to say about point. Basically in a
C++ we should have one mechanism to implement compile time reflection This
is registering type, and functions-type. And compile time reflection which
was proposed, in hl library it is only this step by some approaches.
could I point C++ code
void (my_function)(int (first), int (second))
void (foo)(my_reflected_type (first), int (second))
void (on_service_call)(my_reflected_type (first))
std::cout << first.my_field0 << std::endl;
void main_call(std::wstring const& json)
// get boost::v_item<my_reflected_type, my_reflected_type0, 0> classes
extract<ex<classes_stg> >::type classes;
// get boost::v_item<foo_accessor,
my_field1_accessor,0> ,0>, 0> accessors
extract_class <my_reflected_type0>::type accessors;
It's really working, without fusion, we can make fields and methods in
a different scope .
2014-12-08 21:50 GMT+02:00 Damien Buhl <damien.buhl_at_[hidden]>:
> Hi Peter,
> Were you at the meetingcpp in Berlin ? I also was there, sad that we
> didn't got in contact, because I've been working on such kind of things
> for a while now (many years, from compiler plugins for gcc, clang to a
> c++-only / macro / template metaprogramming version).
> I would find it nice to see something good solving the issue of remote
> procedure call and data field synchronization, because I've a
> not-so-much working solution that I want to opensource at some point
> when it will be good enough, but it would be of great benefit to get
> others ideas/impl, because I've been essentially working alone and I'm
> at the 5th rewrite already. :p
> In any case I would be really interested on such a library. For example
> you could use mechanisms like BOOST_FUSION_ADAPT_STRUCT to
> "automatically" introspects classes in order to generate as well
> serialized output and function calls. We could even add extensions to
> fusion to allow more introsprection of adapted types.
> What I want when I'll get my last changes on BOOST_FUSION_ADAPT_STRUCT
> working on MSVC too, is to improve it in order to have it automatically
> generate the boilerplate code to implement compile time reflections
> proposals to iterate over structs or adt fields, bases etc. And to
> implement an API near to the proposals ones.
> I'm wondering how I could use Abel's Sinckovicks metaparse library to
> improve the emulation for compile time reflection support, so that it
> don't need to specify fields manually.
> I think there already is Boost.Rpc in the sandbox, but I feel it didn't
> evolved much lastly or am I wrong ? Do you meant basing your work on it ?
> Regarding Boost HPX, I believe they already is an internal library for
> this kind of automatic remote rpc, did you mean to use their serializers
> based on spirit and so ?
> I've always been dreaming of things like : auto remote_obj =
> remote_obj->remote_field = "assign it remotely";
> So yes I would definitely love to see others people working on these
> points, and could even give a hand because I anyway invest weekly time
> in this topic alone in my cellar :) .
> Damien Buhl
> On 12/08/2014 03:27 PM, Peter Bindels wrote:
> > Hi all,
> > I've searched through the Boost mailing list history to find related
> > and the last I found was from January where Oleg Labutin and Hartmut
> > discussed compile-time reflection in the context of RPC mechanisms.
> > Based on Hartmut's speech last Saturday introducing HPX and explaining a
> > bit about async/future/promise I tried to implement a simple RPC
> > that uses then to decouple work and the result I have so far is very
> > promising. I have a simple interface with a call that returns a future,
> > the caller does not distinguish between calling the actual object and
> > calling on a proxy, as both return a future<T>. It does what the
> > mentions - serialize the name of the interface and function, as well as
> > arguments (basically the mangled name of the interface function) to
> > there are no mismatches.
> > I would like to take this oppurtunity to propose two things:
> > - I can work on this idea to work it out into a full RPC mechanism, to be
> > proposed for Boost.RPC, if there is enough interest. Currently it uses
> > macros to generate and wrap functions, and a simple serializer that
> > serializes in the same way that Protobuf and Thrift also serialize.
> > - Given a compile-time reflection method, the entire proxy class and
> > dispatch class can be auto-generated from the interface class - the full
> > code for registering an interface with the RPC mechanism would collapse
> > RPC::Register<T>(); To do so, it would need two language additions. It
> > needs access to a compile-time iterator over functions and traits about
> > argument types, return type, name and whether it is a virtual function.
> > the prototype this can be manually generated for an interface to show it
> > works. Additionally, it would need to be able to use such a definition to
> > instantiate a virtual function from a base class - basically, hooking up
> > std::function<X> to a virtual function X directly. I think this is
> > well-implementable (probably reusing most code from lambdas for the link
> > code), but I don't know whether that's true.
> > On the second note, I also proposed a Mock library a few years ago. This
> > basically fell flat on the code that I suggested being very unsafe and
> > using many hackish methods to mock functions. Using the compile-time
> > reflection proposed for the second bullet I would be able to replace the
> > entire hackishness from that with 100% compliant code, with only one
> > regression in functionality. That should make it Boost-OK at least from a
> > language standards perspective.
> > Any ideas? Reactions on RPC or Mocking?
> > Best regards,
> > Peter Bindels
> > _______________________________________________
> > Unsubscribe & other changes:
> Unsubscribe & other changes: