Re: [boost] Is there any interest in a library which solves C++ class reflection feature just like Java does?

Subject: Re: [boost] Is there any interest in a library which solves C++ class reflection feature just like Java does?
From: jinhua luo (ljh.home.king_at_[hidden])
Date: 2011-12-07 05:31:42

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_at_[hidden]>

> On Tue, Dec 6, 2011 at 2:37 PM, jinhua luo <ljh.home.king_at_[hidden]>
> 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
>