Creating debugger-friendly enums for property table - c++

Question

I have a situation where I have a hierarchy of classes: Widget and Doobry are object types that inherit from Base (in reality there's a lot more than 2 types). Each instance of an object has a list of properties. There are some properties that are common to all objects, and some properties that are specific to each item type. A simple implementation might look like this:
enum PropertyType {
COMMON_SIZE=0, // first section: properties common to all
COMMON_POSITION,
...
WIDGET_PROPERTY_START=100, // ensure enough space for expansion
WIDGET_DONGLE_SIZE,
WIDGET_TEXT,
...
DOOBRY_PROPERTY_START=200
DOOBRY_COLOUR
....
};
class Base {
public:
Base();
std::vector<std::pair<PropertyType, string>> properties;
};
This achieves one objective in that in the debugger I can see a list of properties mapped onto meaningful names. However it suffers from some drawbacks:
Properties for all items have be defined in one header (not good for encapsulation)
We have to pick some arbitrary numbers for each of the class start positions to allow enough space for future expansion if we add more properties to one of the classes.
My question is whether there's another way of achieving this objective. One thought is that I could use string constants which would be larger to store and slower to lookup, but have the advantage that it's easier to make the names unique and each item type can define its own properties.
EDIT:
It is required that the properties will be serialised and so must be stable over time (ie the enums don't change). There may be up to 1M objects but the vast majority will have empty property tables (as they use default values). Lookup performance is more important than insertion, and the performance hit of doing a string hashing is probably negligible (we can't measure whether it is yet as we haven't written it!).

Answer 1

struct UniqueTag {
friend TagManager;
char const* tag;
UniqueTag( UniqueTag const& other):tag(other.tag) {}
UniqueTag():tag(nullptr) {}; // being able to create the null tag is useful
bool operator<( UniqueTag const& other )const{ return tag < other.tag; }
bool operator==( UniqueTag const& other )const{ return tag == other.tag; }
// do other operators
private:
UniqueTag( char const* t ):tag(t) {}
};
#include <map> // or unordered_map for performance
class TagManager {
std::map<std::string, UniqueTag> cache;
std::vector< std::unique_ptr< char[] > > data;
public:
TagManager() {};
UniqueTag GetTag( std::string s ) {
auto range = cache.equal_range(s);
if (range.first != range.second) {
return range.first->second;
}
std::unique_ptr< char[] > str( new char[ s.size()+1 ] );
std::copy( s.begin(), s.end(), &str[0] );
str[s.length()] = '\0';
UniqueTag retval( str.get() );
data.push_back( std::move(str) );
if(s.length()==0) {
retval = UniqueTag(); // empty string is null tag, so we don't have both!
}
cache.insert( range.first, make_pair( std::move(s), retval ) );
return retval;
}
};
A single TagManager maintains a bunch of unique pointers to strings. We can do fast comparison because we compare on the pointer value. Converting from a string to one of the unique tags is slow, and it has the anti-pattern of a single tag manager implied, but...
Alternative versions include having your UniqueTag stick a hash next to itself, and look things up on the hash (with some kind of assert that no two strings hash to the same value in debug -- birthday paradox makes that happen far more likely than one would naively expect). This gets rid of the single manager class (at least in release -- in debug, you'd have a way to detect collisions. If your hash is deterministic, the lack of collisions in debug could imply no collisions in release).
A boost::variant<enum1, enum2, enum3> with appropriate visualizer and some operator overloads would let you have multiple independent enums. Or a home-brew union over enumes, with a primary enum that says which is valid, with a visualizer on top of it would let you split up management all over the place. In both cases, you export the index of the "type" of enum, then the enum value -- so the order of the enums has to be stable, and the values within each enum have to be stable, but no magic integers are needed. To check for equality, a two-integer chained comparison is needed instead of one (which you could hack into a single 64 bit comparison, if that is faster).