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

Subject: Re: [boost] [mirror] automatic reflection / boost.mirror still in development?
From: John B. Turpish (jbturp_at_[hidden])
Date: 2009-08-22 08:00:36

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_at_[hidden]> wrote:
> 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.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>