Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk