Hi, ok, it's hard to explain every detail before I publish my codes somewhere (I'm preparing to publish it). Anyway, let me introduce some principles of my understanding of the "reflection": a) it should be simple and clear enough, which means it doesn't require the user to get much background knowledge before he can apply the library into his application. So either the macro declaration or the API should be clear or even be familiar with (that's why I choose Java style API, and I care about practicability). I hope learning the library usage just like learning how to write a "hello world". b) the reflection should be general, not specific to any domain purpose c) the reflection should be real reflection, i.e. you can reflect your declared class at runtime specified by qualified class name string, and you don't need to make your program compiled with any C++ codes related to that class, e.g. class definition and implementation (in my example, the main program is the program to use the reflected classes, and it knows nothing about the class definition and implementation, which in turn is compiled into another shared library), and I think that's the magic of the reflection. I know there exists many reflection implementation, and every implementation has its advantages and disadvantages, I think. And my implementation is a light-weighted but useful enough one, I believe. Regards, JinHua 2011/12/7 Matus Chochlik <chochlik@gmail.com>
On Tue, Dec 6, 2011 at 2:37 PM, jinhua luo <ljh.home.king@gmail.com> wrote:
Hi,
OK let me say this so you don't get me wrong: I welcome any attempt to add reflection to C++, I would very much like to have reflection in the C++ standard with the full support of the compiler, and I don't care on whose design it is based.
What I care about is that it is done properly, i.e. that it is not tailored for a specific goal ORM, Serialization, RPC, GUI geneation, parser generation, whatever .. but that it would support all of these and much more. It should provide as much meta-data as possible even if some of it might not be obviously usable in some scenario (it might be in others), etc.
It also should be compile-time because then you can use it with all the great meta-programming tools implemented in Boost and elsewhere. If you have a solid compile-time foundation you can implement run-time reflection even, dynamically loadable easily.
I have a quick look at the Mirror reflection utilities, although no deep investigation, I have some opinions about it:
a) complex reflection declaration syntax (e.g. to describe the prototype of some method, it needs to use macro per parameter, but in my way, it's more easier and native: you just need to copy and parse the prototype from the class definition)
The syntax is complex only if you need to specify all details manually. There are however the quick-registering macros that simplify the registering quite a lot.
b) depends on C++11 features (as mentioned in the web site, It has been tested and is currently known to work with the gcc 4.5.1 and higher), but my way does not require new versions of C++ standards, so it supports VC7 or higher, and all gcc versions.
C++11 is a standard now and Mirror (AFAICT) doesn't use anything gcc-specific. I know that the release cycles for compilers are quite long, but I hope that we'll get good if not full support for C++11 soon.
c) the source codes of the Mirror reflection utilities is a bit huge and complex than my one: my reflection library has only 3 header files and 1 source file, and the codes are about 1200 lines.
It is true that Mirror is a big library, but to do some basic things you certainly don't need to include every header. Much of the source code implements "higher-level" tools on top of the basic reflection. There is still some mess in the header organization, but I want to have all that fixed in future releases.
Regards, JinHua
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost