Re: Factories, handles, and handle wrappers
On Dec 19, 12:31 am, Michael Mol <mike...@gmail.com> wrote:
On Dec 17, 7:52 pm, James Kanze <james.ka...@gmail.com> wrote:
On Dec 16, 1:50 pm, Michael Mol <mike...@gmail.com> wrote:
Let's say you have a factory which returns handles to
objects that it allocates. You pass these handles to the
factory whenever you want to use the object or destroy it.
The factory's "OperateOnObject" class verifies that the
handle is within its object collection, and then marshals
the OperateOnObject call to the class's internal
OperateOnObject method. All external operations on the
object instance are required to pass through the Factory
in order to guarantee that the object instance is still
valid at the time of call. This leads to code roughly
like this. (Not using exceptions here, but rather return
error codes.)
This is overly complicated; most importantly, it renders
client code unnecessarily complicated. The simple solution
for this is:
1. Install the Boehm garbage collector and use it for these objects.
2. Define a flag in each object, which is set in the constructor, and
reset in the destructor.
3. Check this flag each time you use the object.
While I'll admit that the current code has flaws in this area,
how does setting a class member "AmIValid" flag guard against
dereferencing an uninitizialized or wild pointer? In either
case, I have an instant crash. (In most such circumstances,
the current code triggers a hard breakpoint in debug, and a
null-op return in release. The only remaining circumstance
hasn't been seen, but is presumably possible.)
It can't do much with regards to a wild pointer (initialized to
some random value). On the other hand, in the above scenario,
the destructor of an object will reset the flag, and garbage
collection will ensure that the underlying memory is not reused.
If all of the member functions check the flag, and if there are
no public data members, all use of a destructed object can be
detected.
More fundamentally, how does it guard against a stale pointer
that winds up pointing to memory overwritten due to some other
heap allocation?
That's why you need garbage collection, point 1 above. After
installing the Boehm collector, you provide a global operator
new function which calls gc_malloc, and a global operator delete
function which does nothing. As long as there is a pointer to
the memory (and sometimes longer), it cannot be reused.
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]