C++ Reflection and Service Library

This site is hosted at

Project Links

• Project overview
• Project's CVS repository's web-interface. Take a look! I put the current version into CVS again.
• The doxygen-generated reference manual
• An introduction into my recent direction conecrning C++ reflection. The results will build the foundaton of a layered reflection system, that will be useful to applications with high demans on performance as well as normal business applications.

Current state

Somewhere I heard that the 3rd try is the big one... we'll see. The 1st redesign focused on making the reflection data available at runtime. So I wrote the code and mixed in a lot of template stuff to get the API more type-safe and to give application developers some syntactic sugar. There were two major problems with this:

1. I mixed in the templates. There was no architectural difference between the point of the software "Reflect C++ types" and the syntactic sugar and other convenience things.
2. Later in the development of the library if found some new requirements (have a look at this road map) that didn't work well together with the existing compile-time logic (Templates! They're not all bad, but...). That led me to big, unhandy and not really elegant code.

1. Now, I try to really focus on the reflection part (no sugar!).
2. And I try to make all reflection data available at runtime.
3. When everything works fine, I'll wrap some syntactic sugar etc. around it.

By the way, I picked up the idea with the FFCall library when I realized that GCC allows me to convert bound member function pointers to plain function pointers! And it looks real promising. Telling the reflection classes about the return type and the type signature of a classes member function, I'm able to call it without writing glue-code.

The 1st smoke test for the member function call will be something like remote method calls... (back in ??? minutes - coding!)

Yes, I'm still here. But in between I worked on quite a lot of other things. And I got another (one more) view on C++ reflection. This time, I won't promise something about a wonderful, full featured reflection framework. But myabe I may link the curious to some current results.

The last days I was busy rewriting the whole thing again, because I was not really satisfied with the latest development results. I mixed up too many different things at once. So I decided to have a clean start and use all the things I had learned in between about a reflection library for C++.

I'm currently working on making the ClassType reflector reflect derived Classes, too. While doing that, I prepared the ClassType to reflect compiled classes as well as dynamic emitted classes. Maybe the dynamic emitted ClassTypes could be useful, if you want to embed scripting languages into your application?

However, accessing member-data from reflected objects without having their real, final type at compile-time proved to be a real problem (You may have noticed, that the unit test "utPolymorph" always reported an address deviation different from 0). Today I had a break-through in solving that problem. But the solution only comes at the cost of breaking the member-access control that was introduced through the class MemberAccess. I decided to do it anyway, because it could make things possible, like loading a shared library at run-time and then applying e.g. a serialization-service to completely unknown objects that were constructed from that lib without the lib ever knowing the serialization-service!