I recognize that your use case is probably different from the one I contrived for my example, and without a lot more details I won't be able to make one that matches (I also think that if you had a lot of details you would be able to find a solution yourself).
#include
#include
Shortcomings:
- Storage structure is read-only. This is a necessary shortcoming, because the index will become outdated if you modify the indexed fields of an object while it's in the datastore. To modify an object, remove it and then re-add another one.
- All fields must be unique. This is easily changeable, but you need to keep maps containing
list
as indices for non-unique fields, not just maps containing Thing
.
- Performance problems relating to using
std::map
. std::unordered_map
is an alternative with better (constant amortized) access times for huge data structures (the same as std::unordered_set
).
Deviations:
- Given that you have a clear key-value relationship here, I think you'd be better off with a map than a set.
- In order to solve performance problems relating to reference counting, if you are careful to maintain the internal consistency at all times, you could forgo all smart pointers for raw ones, and return values via references, and you could achieve further improvements by using unsafe object ownership semantics when filling it (i.e., pass it pointers to heap objects that the Datastore then takes ownership of). More complex, but ultimately fewer copies and less runtime overhead.