Re: [boost] Compile time reflection for IPC using

Subject: Re: [boost] Compile time reflection for IPC using
From: Oleg Labutin (ol.labutin_at_[hidden])
Date: 2014-01-22 07:21:44

   Also I seen that inside you use BOOST_TYPEOF in
../hpx/runtime/actions/action_support.hpp. In this case we should use
BOOST_REGISTER_TYPE, this approach implemented by specialization (in MSVC
__if_exists) but we can't make type_list used this. Therefore we can't use
this approach in context RPC/IPC with serialization. TO able to serialize
and full IPC\RPC we should iterate by identifiers, args, methods, fields,
etc. Approach I proposed allows it.

2014/1/22 Oleg Labutin <ol.labutin_at_[hidden]>

> First: Approach I proposed based on registration a types (and calculation
> type), it can be anything f.e.
> namespace hl {
>
> template <typename Type
> , typename Return
> , typename... Params>
> struct parse_signature
> {
>     typedef Return (Type::*Function)(Params...);
>     template <Function Func>
>     struct specify
>     {
>         static constexpr Function
>         func()
>         {   return Func;    }
>     };
> };
>
> // This function should return the type from which we can get type of this
> function
> template <typename Type
> , typename Return, typename... Args >
> inline parse_signature<Type, Return, Args... >
> _func_get_signature__(Return (Type::*ptr)(Args...));
>
> #define HL_FUNCTION_TYPE(func) \
>         decltype(_func_get_signature__(func))::specify<func>
> }
>
> REGISTER_TYPE(decltype(_func_get_signature__(func))::specify<func>);
> // This workabel on a gcc 4.7 c++11
> // Also as u can see I can register type on any function
>
>    This approach full covered approach you proposed. But compile time
> reflection this is more deep question, I have to make approach in which I
> can iterate by arguments (all signatures of methods), I need to iterate by
> methods and fields, Also I can iterate by all types which is registrate in
> architectures. In general I have full meta information about architecture
> in which I use this approach. It can be f.e. data base structures. And this
> structures will be very easy and soft, because all metadata is typelist.
>
>     Second. Type calculation this is more deep question we can have many
> concepts. I used this approach in syntax analyzer C++ && Bison, in which I
> type calculation was used as rules, by which was native C++ types it was
> very comfortable and obviously.
>
>
>
>
> 2014/1/21 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>
>
>>
>>
>> > > >  Do you now about one approach (for two compilers (gcc 3.7, and MSVC
>> > > > (last)) emulate compile time reflection with difference scope?
>> > > >
>> > > > Like
>> > > >
>> > > > struct some {
>> > > >       META_STRUCT(some);
>> > > >
>> > > >       FLD(int, a);
>> > > >       FLD(int, b);
>> > > >
>> > > >       METH(int, call_0, (int, a));
>> > > >       METH(int, call_1, (int, b));
>> > > > };
>> > > >
>> > > > void in()
>> > > > {
>> > > >       typedef hl::reflection_extract<some>::field_accessors acc;
>> > > >       some s;
>> > > >       s.*hl::at<acc, a_accessor>::get() = 5; }
>> > > >
>> > > > We can see here https://github.com/ol72/hl/tree/ And you can try to
>> > > > compile this attached demo
>> > > >    Use __J_ACTIVE define to see as reflection worked in json
>> > > > oriented
>> > > part
>> > > > of project. For which you should install json. Without this you can
>> > > > see ability take meta information by query.
>> > > >
>> > > > But global goal I think we understanding Our backend can be
>> > > > something else. Like client server , data base oriented structures
>> > > > in which we can use by SQL like C++ syntax
>> > > >
>> > > > We can make (and I made it )
>> > > > database like structures
>> > > >
>> > > > struct human_tables {
>> > > >    TABLE(names)
>> > > >    {
>> > > >        fields((int) index, (std::string) name, .... );
>> > > >    };
>> > > >
>> > > >    TABLE(country) { fields((names_table::index) name, ... ); };
>> > > >
>> > > >    TABLE(human)
>> > > >    {
>> > > >        indexes(names_table::index_field);
>> > > >
>> > > >        fields((names_table::index_field) name,
>> > > > (country_table::index) country...);
>> > > >    };
>> > > > };
>> > >
>> > > I think that CT reflection is a feature too low level to be exposed to
>> > > users if you want to implement IPC or RPC. And your proposed syntax
>> > > supports this claim as it is way too cumbersome for this purpose.
>> > > However, it certainly is desirable to have something like CT
>> > > reflection at your tool belt in order to implement IPC/RPC.
>> > >
>> > > I'd rather would like to see a functional interface which allows to
>> > > invoke a function remotely in the same way as you'd invoke it locally.
>> > > For instance:
>> > >
>> > > int func() { return 42; }
>> > >
>> > > REGISTER_FUNCTION(func);  // defines func_type
>> > >
>> > > The type defined by the macro ('func_type') is a (very lightweight, no
>> > > members) callable type, which can be used to invoke the remote
>> function:
>> > >
>> > > Synchronous invocation:
>> > >
>> > >     func_type func_impl;
>> > >     cout << func_impl(target);   // 'target' is some means to identify
>> > the
>> > > remote process
>> > >
>> > > Asynchronous invocation:
>> > >
>> > >     future<int> f = async(func_impl, target);
>> > >     // do other things
>> > >     cout << f.get();             // prints '42'
>> > >
>> > > Similar things can be done for member functions and variables (global
>> > > and member data).
>> > >
>> > > If you'd like to see this in action, this scheme is implemented by HPX
>> > > (https://github.com/STEllAR-GROUP/hpx/).
>> >
>> > I think this is not CT.
>>
>> The code I showed is CT for sure.
>>
>> This REGISTER_FUNCTION(func) expands to (amongst other things, mostly
>> related to serialization):
>>
>>     typedef make_action<decltype(&func), &func>::type func_type;
>>
>> where 'func_type' is something functionally equivalent to:
>>
>>     struct func_type
>>     {
>>         // note the operator() exposes the same prototype as func()
>>         int operator()(<implementation-defined> target) const
>>         { /* do IPC/RPC as needed */ }
>>     };
>>
>> Additionally you need special overloads for async(), but that's obvious.
>>
>> HTH
>> Regards Hartmut
>> ---------------
>> http://boost-spirit.com
>> http://stellar.cct.lsu.edu
>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>