C++ Reflection and Service Library |
This site is hosted at |
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:
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.
29. November '03The 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++.
13. September '03I'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!