Jeremy,
What you want to do would require storing a great deal of extra information, in addition to that stored by Boost.Reflection. Since one of my primary emphases is performance, I doubt that my library is an ideal framework upon which to build what you propose. I would imagine though that much of the code could be very useful to you.
Is it so? It's just one extra pointer per field. Hmm. For what I have in mind I also need to ask to a class what its subclasses are...
Have you looked at GCCXML? It could very well give you much of the functionality that you desire (class names, function names and signatures, types with data etc.)
It looks nice but it's gcc-specific. Currently I use MS Visual Express 2008.
I'm not sure if the version of Boost.Reflection in the Sandbox contains the inheritance code. If not, I'll just need to make sure I have unit tests together for it and then I'll submit it.
I'm really curious :-)
Given the normal speed of C++ evolution, I expect to wait quite a while before being able to write multi-methods.
Oh but we don't wait: we emulate them. They won't be very fast but for my needs it's not very important, as I plan to use them to build graphs of objects that mirrors the graph of reflection objects - then put the real functionality in the new graph as regular methods. Now there's a problem. I have been asked via private email to show my code. I have commit access to the sandbox. I see that there is no reflection directory at the top level yet, instead you use boost/reflection and libs/reflection. However I assume that you want to reorganize your library to follow the suggested layout? And thus use boost/reflection? What's the normal way of solving this problem? We have a bit of luck though: you use namespace boost::reflections - and I use boost::reflection sans s. Jean-Louis