On Fri, Sep 10, 2010 at 2:52 AM, Alec Chapman <archapm@fas.harvard.edu> wrote:
Matus Chochlik wrote:
The Mirror reflection library (http://bit.ly/bn7iYM), does something similar for input dialogs for constructing new instances of nested types with possibly multiple constructors. Look for the factory generator utility in the docs. Here (http://bit.ly/bqNqah) can also be found some images of gui dialogs automatically generated by this lib.
That looks interesting. Without having looked at the code, my main question is how closely is the dialog rendering tied to the reflection mechanism? If I'm using a class from a library that I can't modify, is there a way to make it provide the information your library needs? If so, it could be a useful starting point.
The factory generator is built on top of the basic compile-time reflection. It uses the meta-data describing the class constructors to create a factory for a particular type using application specific means of getting input data for the constructors. This means that you can create not only GUI-based factories but factories that can use other data sources (a database dataset, an XML document, etc.) There are some examples showing this here http://bit.ly/dC4fn0. (see the mirror/example/factories/*.cpp) The Lagoon run-time layer built on top of Mirror also allows to create factories dynamically by using run-time polymorphism, but this is still work-in-progress and the resulting code tends to be bloated. The library is non-intrusive i.e. in most cases you do not need to modify a class in order to reflect it. That is unless you want to reflect private members that do not have public getter/setter functions. This is however (at least in my in my experience) usually not a good practice anyway. The classes need to be manually registered with Mirror, (http://bit.ly/bLjQFI explains how). Besides this I'm looking for a suitable tool of automating the registering and integrating it into the build process. [snip] BR Matus