Re: [boost] Compile time reflection for IPC using

Subject: Re: [boost] Compile time reflection for IPC using
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-22 08:09:03

>    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.

BOOST_TYPEOF is only used for older compilers. For newer compilers it uses
decltype().

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> 
> 
> 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
> >>
> >
> >
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost