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 08:52:06
Could you write some codes to implement the same example I showed in my
first mail? That is, define a concrete class in the shared library, and
declare/register it there, while the main program just dynamically loads
the shared library (note that do not need any initialization, just dlopen
is enough, do not need any symbol exported there and be loaded via dlsym),
reflects the class, invoke its methods, access its members.
Then we can have more clear comparison regarding the same context between
2011/12/7 Matus Chochlik <chochlik_at_[hidden]>
> On Wed, Dec 7, 2011 at 2:21 PM, Roman Perepelitsa
> <roman.perepelitsa_at_[hidden]> wrote:
> > 2011/12/7 Larry Evans <cppljevans_at_[hidden]>
> >> On 12/07/11 06:51, Roman Perepelitsa wrote:
> >> > 2011/12/7 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
> >> >
> >> >> So please, don't start a discussion stating that we need a
> >> >> compile-time/run-time or c++11/c++98 library. All the combinations
> >> its
> >> >> usage, each one with its advantages and liabilities.
> >> >>
> >> >
> >> > Point is that it's possible to build runtime reflection on top of
> >> > compile-time reflection, but the opposite isn't true. One can even
> >> > that runtime reflection *must* be implemented on top of compile-time
> >> > reflection, so proposing *just* runtime reflection is pointless.
> >> Hi Roman,
> >> Could you please show an example run-time reflection being build on top
> >> of compile-time reflection
> > Mirror is such a library.
> Compare for example this:
> with this:
> both applications do similar things; print the "kind" (type,
> namespace, template,
> etc.) of a member of a namespace and its name.
> The first uses compile-time reflection, the second uses run-time reflection
> and the run-time meta-objects are based completely on the compile-time
> Also, in the run-time case, there is nothing (that I know of) preventing
> from using just the meta-object interfaces in your application,
> compiling their implementations (the actual meta-objects) into a separate
> dynamic library / shared object and loading and querying them on demand
> from the application.
> for more examples of compile-time vs. run-time reflection see here:
> and here:
> or just start a the main page of the docs:
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk