On Tue, Dec 6, 2011 at 12:40 PM, jinhua luo <ljh.home.king@gmail.com> wrote:
Hi,
In brief, I'd designed and implemented somehow C++ class reflection based on boost libraries. It has some unique advantages: a) it doesn't require code generator
Interesting. Have you thought about how this would be better implemented as part of the compiler, so that you don't have to actually explicitly reflect a type using macros?
b) platform independent and compiler independent (I tested it on Windows and Linux, with vs2008 and gcc respectively)
I guess since this is all runtime values, as long as you're using standard C++ it shouldn't be a problem. Interesting to note anyway.
c) it's non-intrusive for the class definition, instead, you just need to declare and describe your class via some straightforward macros anywhere (header file or source file, and may be within any namespace), which also means you can wrap an external third-party library (which you have no way to touch the source codes) and reflects it classes.
I like this.
d) Cross shared library boundary, you can dynamic load the shared library and reflect the classes within it, without need to export any symbol manunally in C wrapper function way
Cool
e) the API looks like Java reflection API
Okay, this part I'm not excited about. I have two questions here: 1) How do you handle invalidation of objects that are instantiated from a certain type that's reflected when the reflected type changes? How do you handle say when a new method is added? How do you handle changing method signatures? 2) In case of a name collision, how does your library behave? I'm interested because I'm working on a paper that addresses this issue with changes to the language in mind. It's interesting to see yet another way people are solving this with a library solution. Cheers -- Dean Michael Berris http://goo.gl/CKCJX