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 09:46:40

Hi Matus,

If the reflection requires explicit symbol export/import, then it's not so
flexible.
For example, then you must place the Marco declaration within one and only
one source file due to the ODR (One-Definition-Rule), but can not place it
anywhere, e.g. the header file. However, the latter one is more reasonable
and convenient, which makes your macro declaration just follows its class
definition together.
Another problem is if there exists many classes to be reflected, then your
library should export an auxiliary symbol per class, which is not a good
thing, I think, at least it will cause symbol naming collision.
Last but not least, consider such scenario:
the main program declares some classes, and the codes within loaded library
try to reflect them and use them, i.e. the roles exchanges between them.
Then it's not so possible to export some symbols in the executable on some
platforms for access by the shared library (of course, on Linux, you can
export symbols from executable via "-Wl,-E" linker options, but that's also
bad development practise).

Regards,
JinHua

2011/12/7 Matus Chochlik <chochlik_at_[hidden]>

> On Wed, Dec 7, 2011 at 2:52 PM, jinhua luo <ljh.home.king_at_[hidden]>
> wrote:
> > Hi Matus,
> >
> > 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.
>
> JinHua,
>
> I'm unfortunately up to my neck in other projects right now :),
> so I cannot come up with a working example right away,
> but I may try if I'll have some free time.
>
> But anyway, I don't think that the constraints that the library
> should not export anything explicitly are necessary. It always
> can be done with a macro in the library code.
>
> Also I don't see why the application should not use
> dlsym / GetProcAddress (at least indirectly). This could
> easily be hidden in the reflection code that the app uses
> to get the meta-data.
>
> Best,
>
> Matus
>
> >
> > Then we can have more clear comparison regarding the same context between
> > two libraries.
> >
> > Regards,
> > JinHua
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>