Re: [boost] [mirror] automatic reflection / boost.mirror still in development?

Subject: Re: [boost] [mirror] automatic reflection / boost.mirror still in development?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-08-21 11:45:33

On Fri, Aug 21, 2009 at 9:32 AM, <strasser_at_[hidden]> 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.