Re: [boost] [RPC] Compile-time reflection for RPC and mocking

Currently hl availble on https://github.com/hl-plus/. And certain module in which used compile time reflection is https://github.com/hl-plus/hl/blob/master/include/hl_ipc/luna_service_backen... (Obviously register_service(Service* svc) should be called for all sevices by iteration type list.) But I guess it very specific and related to luna (dbus based calling) service. And I hope, I can make more suitable for explanation simple project for demostrate tomorrow. Thanks 2014-12-08 22:54 GMT+02:00 Damien Buhl :

Thanks Oleg for pointing it out, I remember the discussion about it on this list for some month.

Is there any documentation available or example we can compile and play with about your hl library ?

Cheers ;)

...

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

struct my_reflected_type { void (my_function)(int (first), int (second)) {

}

Field(int, my_field0); Field(std::string, my_field1); };

REGISTER_TYPE_SERVICE(classes_stg, my_reflected_type);

struct my_reflected_type0 { void (foo)(my_reflected_type (first), int (second)) {

}

void (on_service_call)(my_reflected_type (first)) { std::cout << first.my_field0 << std::endl; }

Field(int, my_field0); Field(std::string, my_field1); };

REGISTER_TYPE_SERVICE(classes_stg, my_reflected_type0);

void main_call(std::wstring const& json) { my_reflected_type0().call_by_json (getjson(json), 0);

// here // get boost::v_item classes typedef typename extract >::type classes;

// here // get boost::v_item ,0>, 0> accessors typedef typename extract_class ::type accessors;

typename find_meth_by_accessor::type accessor; }

It's really working, without fusion, we can make fields and methods in a different scope .

Thanks

2014-12-08 21:50 GMT+02:00 Damien Buhl :

...

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 = std::make_remotely_shared<MyClass>();

remote_obj->call_remote_service(); 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 :) .

Cheers, -- Damien Buhl

...

Hi all,

I've searched through the Boost mailing list history to find related emails and the last I found was from January where Oleg Labutin and Hartmut Kaiser 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 mechanism 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, and 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 discussion mentions - serialize the name of the interface and function, as well as

...

arguments (basically the mangled name of the interface function) to ensure 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 to 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

On 12/08/2014 03:27 PM, Peter Bindels wrote: the the

...

argument types, return type, name and whether it is a virtual function. For 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 an std::function<X> to a virtual function X directly. I think this is well-implementable (probably reusing most code from lambdas for the

...

...

...

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

On 12/08/2014 09:46 PM, Oleg Labutin wrote: link the

...

...

...

entire hackishness from that with 100% compliant code, with only one minor 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: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost