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 05:20:27

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
>