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:10:15

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

Don't get me wrong, please. I'm not saying your library is bad or anything.
What I said is that I'd prefer a higher level interface when all you need is
IPC/RPC.

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

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