Compile time reflection for IPC using
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...); }; };
On 01/17/2014 08:10 AM, Oleg Labutin wrote:
Do you now about one approach (for two compilers (gcc 3.7, and MSVC (last)) emulate compile time reflection with difference scope?
Compile-time reflection is currently being investigated by SG7 (the C++ standardization workgroup for reflection) http://isocpp.org/std/the-committee https://groups.google.com/a/isocpp.org/forum/#!forum/reflection
Thanks. But I see many attempts to resolve this problem in boost::fusion e.g. But it approch can't resolve problem different scope for fields Like FIELDS((int) _1, (char) _2) my_struct; but not struct my_struct { FILD(int, _1); METH(int, call_1, (int, char)); ... METH(... call_N ...) }; Therefore I think this question is actual now in context boost. Because in approcah I sent we can collect any meta information compile time. And I canm say it is not only compile time reflection This is very comfortable approaches to designe. like struct rule_on_1_case { struct roles { struct on_begin_1_case; struct on_end_2_case; }; }; REGISTER_RULE(rule_on_1_case); struct rule_on_2_case { struct roles { struct on_begin_2_case; struct on_end_1_case; }; }; REGISTER_RULE(rule_on_2_case); .... N rules, or anythink in different scope After which we can collect all types typedef typename hl::manual_extrcat<rules>::type rules_typelist; // boost::v_item<rule_on_1_case, boost::v_item<rule_on_2_case, boost::mpl::na, 0>, 0> And do somethink . Compile time reflection it is only one case when this approcah can be used 2014/1/18 Bjorn Reese <breese@mail1.stofanet.dk>
On 01/17/2014 08:10 AM, Oleg Labutin wrote:
Do you now about one approach (for two compilers (gcc 3.7, and MSVC (last)) emulate compile time reflection with difference scope?
Compile-time reflection is currently being investigated by SG7 (the C++ standardization workgroup for reflection)
http://isocpp.org/std/the-committee https://groups.google.com/a/isocpp.org/forum/#!forum/reflection
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
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/). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
I think this is not CT. 2014/1/19 Hartmut Kaiser <hartmut.kaiser@gmail.com>
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/).
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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@gmail.com>
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
Also I seen that inside you use BOOST_TYPEOF in ../hpx/runtime/actions/action_support.hpp. In this case we should use BOOST_REGISTER_TYPE, this approach implemented by specialization (in MSVC __if_exists) but we can't make type_list used this. Therefore we can't use this approach in context RPC/IPC with serialization. TO able to serialize and full IPC\RPC we should iterate by identifiers, args, methods, fields, etc. Approach I proposed allows it. 2014/1/22 Oleg Labutin <ol.labutin@gmail.com>
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@gmail.com>
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
Also I seen that inside you use BOOST_TYPEOF in ../hpx/runtime/actions/action_support.hpp. In this case we should use BOOST_REGISTER_TYPE, this approach implemented by specialization (in MSVC __if_exists) but we can't make type_list used this. Therefore we can't use this approach in context RPC/IPC with serialization. TO able to serialize and full IPC\RPC we should iterate by identifiers, args, methods, fields, etc. Approach I proposed allows it.
BOOST_TYPEOF is only used for older compilers. For newer compilers it uses decltype(). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
2014/1/22 Oleg Labutin <ol.labutin@gmail.com>
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@gmail.com>
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
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@gmail.com>
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
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@gmail.com>
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@gmail.com>
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
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<type_id<methods_type>::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<call_id_0>(1,2,3,4) .remote_call<call_id_1>("",struct_(1,2,"")).get<value_id>(); And also no calling simple automation like remote_instance.remote_call<call_id>( If_(r_call<call_id_0>() != 5)( r_call<call_id_1>() ) (r_call<call_id_2>([](some_type& v){ }) ) ); In client \ server this is more comfortable and this is no bags tactic 2014/1/23 Oleg Labutin <ol.labutin@gmail.com>
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@gmail.com>
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@gmail.com>
> 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
participants (3)
-
Bjorn Reese -
Hartmut Kaiser -
Oleg Labutin