[mirror] automatic reflection / boost.mirror still in development?
is boost.mirror (sandbox: https://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/ ) still in development? looks a bit abandonded to me. when I first saw it I was not too excited about it because I don't think a reflection library that requires the user to register every c++ construct manually is very usable. but GCC recently (finally) integrated a plugin infrastructure, so it would be possible to automatically generate reflection information. I've worked with the GCC internal tree before, it's pretty close to the c++ constructs in the early stages. something like this would be possible: test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp" class myclass{ int myvar; double myfunction(); }; int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); } //or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; } or anything else you can do with MPL sequences, like iterating over class members. this would have some downsides though: - GCC the library user must install GCC. other compilers can still be used for compilation, but the code to be reflected must be portable to GCC. - license the code generating plugin must be GPLed. that does not affect the license of the user code or other parts of boost though. acceptable downsides imho, given that there are no practical alternatives in sight, like a standard conforming boost C++ parser. what do you think?
On Fri, Aug 21, 2009 at 9:32 AM, <strasser@uni-bremen.de> wrote:
is boost.mirror (sandbox: https://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/ ) still in development? looks a bit abandonded to me.
when I first saw it I was not too excited about it because I don't think a reflection library that requires the user to register every c++ construct manually is very usable.
but GCC recently (finally) integrated a plugin infrastructure, so it would be possible to automatically generate reflection information. I've worked with the GCC internal tree before, it's pretty close to the c++ constructs in the early stages.
something like this would be possible:
test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp"
class myclass{ int myvar; double myfunction(); };
int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); }
//or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; }
or anything else you can do with MPL sequences, like iterating over class members.
this would have some downsides though: - GCC the library user must install GCC. other compilers can still be used for compilation, but the code to be reflected must be portable to GCC.
- license the code generating plugin must be GPLed. that does not affect the license of the user code or other parts of boost though.
acceptable downsides imho, given that there are no practical alternatives in sight, like a standard conforming boost C++ parser.
what do you think?
Sounds acceptable to me, assuming it works with mingw's gcc or you include a compatible version with the library for windows users. Clang might be better to use when it becomes more mature, the library nature of it makes parsing and getting code details rather simple.
Am Friday 21 August 2009 17:45:33 schrieb OvermindDL1:
Sounds acceptable to me, assuming it works with mingw's gcc or you include a compatible version with the library for windows users.
the GCC plugin infrastructure is now part of mainline GCC. I don't know if there was a release version since then, but it will eventually be in every GCC there is, including mingw and cygwin.
ROSE can do similar things too. The thing is, this seems to me to be more the job of a build tool and less the job of a library. You don't want meta information you're not using to end up in the executable, right? Certainly not in production at least. If you were willing to accept that kind of bloat you probably wouldn't be using C++. Well a build tool can just replace references to the meta information with constants or some such, letting the later stages of compilation forget the rest of it ever existed, but it's hard for a library to tell the compiler to maintain only some members of some of these classes. Maybe I'm wrong. It wouldn't be the first time. On Fri, Aug 21, 2009 at 11:45 AM, OvermindDL1<overminddl1@gmail.com> wrote:
On Fri, Aug 21, 2009 at 9:32 AM, <strasser@uni-bremen.de> wrote:
is boost.mirror (sandbox: https://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/ ) still in development? looks a bit abandonded to me.
when I first saw it I was not too excited about it because I don't think a reflection library that requires the user to register every c++ construct manually is very usable.
but GCC recently (finally) integrated a plugin infrastructure, so it would be possible to automatically generate reflection information. I've worked with the GCC internal tree before, it's pretty close to the c++ constructs in the early stages.
something like this would be possible:
test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp"
class myclass{ int myvar; double myfunction(); };
int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); }
//or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; }
or anything else you can do with MPL sequences, like iterating over class members.
this would have some downsides though: - GCC the library user must install GCC. other compilers can still be used for compilation, but the code to be reflected must be portable to GCC.
- license the code generating plugin must be GPLed. that does not affect the license of the user code or other parts of boost though.
acceptable downsides imho, given that there are no practical alternatives in sight, like a standard conforming boost C++ parser.
what do you think?
Sounds acceptable to me, assuming it works with mingw's gcc or you include a compatible version with the library for windows users. Clang might be better to use when it becomes more mature, the library nature of it makes parsing and getting code details rather simple. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am Saturday 22 August 2009 14:00:36 schrieb John B. Turpish:
ROSE can do similar things too.
The thing is, this seems to me to be more the job of a build tool and less the job of a library. You don't want meta information you're not using to end up in the executable, right?
right. the metainformation generated would be compile-time constants only. for the example below, something like: namespace reflection{ struct myclass{ struct myvar{ typedef int type; }; ... if there is a "bloat" issue it is probably compilation time. to be able to map a type to its reflection type (also shown below, with a ::type missing), you'd end up with very large MPL sequences, but you could limit reflection to a desired namespace or some types avoid that.
test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp"
class myclass{ int myvar; double myfunction(); };
int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); }
//or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; }
or anything else you can do with MPL sequences, like iterating over class members.
participants (4)
-
John B. Turpish -
OvermindDL1 -
Stefan Strasser -
strasser＠uni-bremen.de