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