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

  Excuse me, I didn't want to say anything hard, mb this is my english.
But in really we talking about CT reflection (escuse I skip word reflection
in letter when wrote about this is no CT <reflection>). And I want some
ideas about critic and mb advising. ^)) No any critic to you library only
comparing.

2014/1/22 Hartmut Kaiser <hartmut.kaiser_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.
>
> 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
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>