John Rohlf (jrohlf++at++tubes)
Tue, 24 Jan 95 11:20:04 PST
pfGSetDeletor is 1.0 only and has gone away in 1.2.
pfDelete does use pfFree for libpr objects (geosets etc) after
confirming the reference count of the object to be <= 0. For
libpf objects like pfNodes, pfDelete calls an overloaded
operator delete().
> To the first question, I don't know! But it does not use pfFree on
> the node itself. If you try to use pfFree, you should get a Performer
> Warning that the node base address wasn't allocated using pfMalloc.
>
> Good question though, I had a similar problem, which I have since
> worked around. But if you import in a model object, and wish to
> make instances of that object (using pfClone), and later call
> pfDelete on the cloned instance, it will also remove (delete) the
> original object!
This should not be. Do you have a test case?
> I didn't get a warm and fuzzy feeling that memory
> allocated for the instance was being freed when just calling
> pfRemoveChild.
We never delete any memory unless you specifically request
it with pfDelete so pfRemoveChild does not delete a child with
no parents. This was a design decision which avoids mysterious
side effects and makes deletion explicit which I feel is
more intuitive.
> Another thing I tried to before calling pfDelete
> on the instance was to increase the reference count above 0, then
> return it to its original state after the call to pfDelete.... Only
> to find that the initial, incremented, and restored reference counts
> were -1, -1, and -1 respectively!
pfNodes do not have reference counts per se. That is, they
ignore pfRef() and its brethren - only libpr objects like
pfGeoSets have reference counts. pfNodes are reference-counted
by their parents. Thus if you wish to increment the
reference count of a pfNode, simply add it to a pfGroup
you have lying around for just this purpose.
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:53 PDT