Re: [boost] Compile time reflection for IPC using

24 Jan 2014


      Ok. I would like to ask you about next
       When we should use the RPC architect should we serrialize the call
with all signature information include identifirers, type of parameters,
name of methods. Also obviously should we calling methods by some native
ID? Also, should we return the types and structures, or some data on a
protocol based? I think yes, this is necessarily for complete RPC or IPC.
Therefore we should have approach which allows serialize structured data
etc.
       But if we can use only call by ID, like
remote_call::value>(1,2,3,4); and that's all. And
server side now about method ID, and count parameters with types, without
autoserialization, and no variadic return value, no variadic types, no
state saving and calling like

auto d = remote_instance
                         .remote_call(1,2,3,4)

.remote_call("",struct_(1,2,"")).get();

And also no calling simple automation like

     remote_instance.remote_call(
                           If_(r_call() != 5)(
r_call() ) (r_call([](some_type& v){ }) )
                );
In client \ server this is more comfortable and this is no bags tactic


2014/1/23 Oleg Labutin 
...
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 
...
...
First: Approach I proposed based on registration a types (and
calculation
type), it can be anything f.e.
namespace hl {
template 
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 
inline parse_signature
_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 
...
...
...
>  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::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::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