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@gmail.com>
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
On Wed, Dec 7, 2011 at 2:52 PM, jinhua luo <ljh.home.king@gmail.com> wrote: 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