The cbProperty class will (along with cbVariant) form part of the SDK for the general and plugins development.
I'm planning to release these basic classes with the wxWidgets license, as all people can use them without licensing problems.
The idea.The idea behind cbProperty is to have an extensible, serializable, and flexible class for holding configuration data - NO MATTER the complexity of the data itself. Being an certified expert in XML, i thought: Why not make it a tree?
And here's what I came up with:
class cbProperty;
class cbVariant; // See the other thread
typedef map<wxString, cbVariant, less<wxString> > cbAttributes;
typedef map<wxString, cbProperty*, less<wxString> > cbProperties;
class cbProperty
{
virtual wxString className() { return _T("cbProperty"); }
wxString TagName;
cbAttributes m_Attrs;
cbProperties m_Children;
};
In other words, a cbProperty consists of associative arrays of cbAttributes (a map of variants, accessible by a string name) and of *cbProperty's, so it can be recursive.
The cbProperty destructor will dispose all of the class' children and attributes. By adding XML serialization, we only have to serialize the top node to serialize all the data.
Notice that the cbProperty class CAN BE subclassed, so you can add functions to query specific properties.
The sky's the limit!In other words, when our compiler configuration can have UNLIMITED PROPERTIES, and is extensible, there will be no need to redesign it again.
Perhaps we could rewrite the CompilerOptionsBase and similar classes, as subclasses of cbProperty.
Opinions, ideas, criticisms?
