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-05 23:46:09

Hi,

I just have a quick look at the boost::fusion. The declaration syntax is a
bit similar, but they are completely different things, I think. And the my
library do not use boost::fusion.

Also have a quick look at the boost::reflect, and I found it's a different
style to fulfill the reflection:

a) my way is non-intrusive, which means it makes no assumption about your
class, e.g. inheritance, or implements any interfaces. Any public class
members (member functions) of any type (even the C++ reference) can be
reflected. But the boost::reflect seems to be focus on the
interface-oriented reflection.

b) in my way, you just need to declare your class via dedicated macros, and
do nothing else, then you can use Java-like reflection API to reflect and
use your classes at run time. And the API do not need any initialization
before you begin to use. All the declared classes will be registered
automatically.

c) The declaration and reflection is separated. In my example, you can see
that the declaration resides in the standalone shared library, while the
reflection API usage resides in any other program, in which program you do
not need to include any concrete class header file, because that's where
the reflection magic happens. But the boost::reflect needs to know about
the interface definition obviously.

d) when the compiler compiles the declaration, it will raises errors if the
declaration is invalid, e.g. the prototype doesn't match the class
definition. So it's type-safe. Moreover, the reflection API will raise
exceptions if you try to launch some invalid reflection, e.g. non-exist
method, wrong method prototype.

e) the declaration is flexible enough. you can place the declaration
anywhere (and within any namespace), which means you don't have to place it
into one single source file. in fact, you don't need to care about the ODR
(One-Definition-Rule) violation, and it will eliminate the duplicated class
registration, and that's why I said you can place the declaration within
the header file, which may be included within any compile unit. You can
even place the same declaration both in the shared library and the
executable.

Regards,
JinHua

2011/12/6 Julien Nitard <julien.nitard_at_[hidden]>

> Hi,
>
> >In brief, I'd designed and implemented somehow C++ class reflection based
> on boost libraries.
>
> I am interested. Could you detail how it differs from
> BOOST_*FUSION*_ADAPT_*
> STRUCT* in boost::fusion ? It seems very similar to me.
>
>
> >It has some unique advantages:
> >a) it doesn't require code generator
>
> Well ... I'd prefer that a code generater be provided: Your syntax is not
> that lightweight, you can compare with boost::reflect that is a non
> proposed library (link https://github.com/bytemaster/boost_reflect).
> If you want to reflect a large number of classes, then your solution is not
> very maintenable (as all solutions without a code generator).
>
> One more thing: your solution is "runtime" reflection, I think in C++ a
> compile time API would make more sense, though, I must say there are
> advantages for both.
>
> Regards,
>
> Julien
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>