Hi, 1) Platform-independent and Compiler-independent is important, then the reflection can be applied to tons of C++ applications. In fact, it's not so possible and feasible to change the compiler, regarding many reasons, e.g. you have no way to change some compilers with commercial licensing and closed-source, e.g. vs2008. 2) As known, C++ is statically typed language, so I think it's meaningless and impossible to change the type at runtime. Of course, the declaration for reflection may only cover a subset of the class definition, as normally you just need to reflect some essential members for use by other application logic.If the declaration changes, e.g. reflect one more method, you need to re-compile it. Since the reflection supports shared library dynamic loading and works across the shared library, so you just need to re-compile the affected part. 3) Due to the flexibility of the declaration, there may exists multiple reflection registration of the same class, e.g. when you place the declaration within some header file, and that header file is included in different compile unit, even among different shared library compilation. The solution is to keep only one registration for the same class (identified by the qualified class name) at run-time, and discards others. Which registration to be kept is in random and unknown, but that's not a problem as long as they are identical. So it's recommended to place the declaration in one header file. Of course, if there occurs the naming collision (different class definitions but with the same class name), the solution is the same: keep only one and discards others. But that's a bad development practise, and I think we should avoid it as much as possible. So that's beyond the reflection topic. Regards, JinHua 2011/12/6 Dean Michael Berris <mikhailberis@gmail.com>
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost