Boost logo

Boost :

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-06 08:04:26


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.


2011/12/6 Dean Michael Berris <mikhailberis_at_[hidden]>

> On Tue, Dec 6, 2011 at 12:40 PM, jinhua luo <ljh.home.king_at_[hidden]>
> 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
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at