I had a quick look at a code example of your library and like to add that it is possible to do this without having to declare a list of members outside the class: -- Stefan Strasser
You're definitively right ! I made the design choice - which of course can be easily debated - to put the 'fields list' outside the class, for some reasons : - It may be useful, in some situations, to 'plug' reflection features on an existing class or struct, without changing it. - A specific application may need several different 'fields lists' on the same class or struct. I like your idea to encapsulate a data member which can, for example, provide clean accessors to these members. Is it possible to have the best of both worlds ? Given a plain, immutable 'Class' struct or class, the different 'fields lists' may be stored in derived classes containing several instantiations of a macro such as your 'FIELD', but which would not instantiate the member, but rather use the one of the base class. -- DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl