When recycling direct pointers into a pool of allocated objects whose lifetimes are controlled by well defined periods (eg session, permanent or temporary ("user")), are there any additional clever security measures I can employ to make sure local copies of these pointers are more likely to not be used outside the object's life cycle?
That is, I'm not able to ensure anything as soon as I emit a raw pointer in the first place, so it's not like I want to prevent the user from being able to segfault the program if they're reckless or go out of their way to do so, but I would still prefer if there was some sort of mental barrier that would ensure the programmer is aware of the pointer's lifetime. These raw references are not to be given out in bulk, but are rather likely limited to something like 1-5 instances. I do not want to make them smart pointers as the pool must be free-able regardless of any dangling references.
Two options I can think of are:
1) add a layer of indirection and instead of providing raw pointers directly hand out internally managed weak pointer style wrappers. These could be set to null when a pool is freed or an object is recycled, but would in no way prevent the programmer from making local copies anyway,
2) force the programmer to use specific context-sensitive calls to retrieve the pointer in the first place that spell out "caveat emptor". Eg something like GetSessionPointer(), GetPermanentPointer() and GetUserPointer().
Cleanup of pool data is performed when a session is terminated (eg when a level/chunk is unloaded), the program closes or the user manually decides to free up temporary memory. A callback is invoked to notify the programmer when this occurs.
In the past I've opted to using individual allocations, but there are a few classes of objects that I wish to manage in bulk (these are mostly related general speed improvements, serialization of level data, etc).
Any thoughts how to add additional security on top of this? What's the best approach in a production environment?