At the same time, there are some reasons to keep "parts" of the system in place. All of the UI items such as descriptions, tool tips, editor types, etc can go away. But some things such as the properties and their types are very useful if you utilize a scripting system. You can kill two birds with one stone and integrate scripting at the same time you are describing the code to the editor. And of course, the root of the system, which I use is a RTTI implementation which I use to replace the limited C++ rtti abilities, so that gets to stay also. (NOTE: I say limited because I attach some additional attributes to describe the class for various reasons used in the engine which C++ rtti doesn't allow.)
Another item to consider, I don't want any non-stack allocation taking place before main enters and gets all the memory systems redirected and setup the way I want them (if at all possible of course). This is not a "critical" point but I'd very much like all the overhead of the RTTI tracked along with everything else. Since it exists from startup to shutdown, it is not a big issue, I just prefer to not miss anything if possible.
Ok, all the rambling explanation aside, here's the current thinking and initial working code examples:
1. Use an initializer chain based system. Even if there are memory allocations off of the stack they will be released prior to entering main. So the idea is basically:
static RttiInfo XXXXClassRttiInfo = RttiDef::Begin( "Someclass" ) .Property< uint32_t >( "Blargo" ) .Get< uint32_t >( &Someclass::Blargo ) .Set< uint32_t >( &Someclass::SetBlargo ) .Description( "Some uint32_t." ) .End()It is verbose (can be wrapped with templates/macro's to simplify most of this to single lines) but the idea is intended to deal with all the items mentioned above. The stack based temporary which "Property" returns simply records the given information in local variables and the "End" puts those variables into the RttiDef which "Begin" put on the stack. In the case of "Description" in a retail build it just returns without doing anything and the string given it "should" be stripped as unreferenced by the linker.
2. The descriptive ability is easily extended in many ways depending on what the tools require/desire and things such as description just compile out to nothing in retail. Min/Max values for a control, type of editor to present, order of controls, groups of controls, whatever you may want.
3. With a bit of work all the remaining retail data can be serialized in the tools and saved with optimized level/area/whatever systems.
So, to do "everything" mentioned is a pretty large undertaking but to get what I want/need right now, I implemented just the editable property system in fairly short order and it compiles out of retail nicely. What I'm looking for here is alternatives, suggestions, etc which fit the desired requirements or are close enough to justify some hacking. A swift kick to the head for missing some library or alternative would be welcome.