Chateauneu Remi schrieb:
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 agree that this is needed("fields I want to serialize", "fields I want
the user to see", etc.) but I don't think this should be part of a
reflection library.
one can still use a std::map
I like your idea to encapsulate a data member which can, for example, provide clean accessors to these members.
I'm not sure what you mean here. the _ClassField in the example behaves like the underlying type. if it's a class type it is derived from it, otherwise it has conversion ops. it has no accessors. -- Stefan Strasser