OBSERVATION ONE
Consider An Important Qt Design: QObjects cannot normally be copied
their copy constructors and assignment operators are private
why? A Qt Object...
might have a unique QObject::objectName(). If we copy a Qt Object, what name should we give the copy?
has a location in an object hierarchy. If we copy a Qt Object, where should the copy be located?
can be connected to other Qt Objects to emit signals to them or to receive signals emitted by them. If we copy a Qt Object, how should we transfer these connections to the copy?
can have new properties added to it at runtime that are not declared in the C++ class. If we copy a Qt Object, should the copy include the properties that were added to the original?
in other words, a QObject is a pretty serious object that has the ability to be tied to other objects and resources in ways that make copying dangerous
isn't this true of all serious objects? pretty much
OBSERVATION TWO
if you have a vector of objects, you often want to track them individually outside the vector
if you use a vector of pointers, you can move the object around much more cheaply, and not worry about costly large vector reallocations
a vector of objects (not pointers) only makes sense if the number of objects is initially known and does not change over time
OBSERVATION THREE
STL vectors can store your pointers, iterate thru them, etc.
for a vector of any substantial size, you want to keep objects sorted so you can find them quickly
that's what my sorted_vector class is for; it simply bolts vector together with sort calls and a b_sorted status
following STL practices, to get sorting, you have to provide operator< for whatever is in your vector
BUT... you are not allowed to do operator<(const MyObjectPtr* right) because it would require a reference to a pointer which is not allowed
BUT... you can provide a FUNCTOR to do the job, then provide it when sorting/searching
a functor is basically a structure with a bool operator()(const MyObjectPtr* left, const MyObjectPtr* right)
OBSERVATION FOUR
unordered_set works even better when combining frequent CRUD with frequent lookups
SUMMARY
Dealing with tons of objects is par for the course in any significant app.
Finding a needle in the haystack of those objects is also standard fare.
Having multiple indices into those objects is also essential.
Using unordered_set with object pointers and is very powerful.
|