Next: Using SQL directly
Up: Database access
Previous: Writing TPhKeyPtr's
  Contents
Once you create a KeyPtr referring to an object, the TPhKeyManager
thinks it 'owns' the object, and might delete it out from under you
(if you've discarded your KeyPtr), or might give someone else a
pointer to that object without telling you. Here are some rules to
follow when working with KeyPtrs:
- Don't make KeyPtr's to objects which are not now or
soon to be stored in the database.
The current implementation forbids this, but that may change
in the future.
- Don't change an object pointed to by a KeyPtr unless you know
what you must.
The current implementation also forbids this, but this may
change since there are too many ROOT functions which are not
const-correct. If it is changed, changing the object a KeyPtr points
would cause others hard-to-find bugs.
- Don't take pointers to the object pointed to by the keyptr
without keeping the KeyPtr itself around. Remember that the KeyPtr is
destroyed when you leave scopes!
If you do this, it is possible that the Key Manager will think
you're done with the object and delete it. Or it might not, if someone
else has a KeyPtr to it somewhere. This is another source of
hard-to-find bugs.
Next: Using SQL directly
Up: Database access
Previous: Writing TPhKeyPtr's
  Contents
Gunther Roland
2000-05-05