Re: Who is releasing my CFAllocator?
Re: Who is releasing my CFAllocator?
- Subject: Re: Who is releasing my CFAllocator?
- From: Ali Ozer <email@hidden>
- Date: Sat, 3 Aug 2002 16:20:56 -0700
turns out I am confused by the documentation. The example says:
static CFAllocatorRef myAllocator(void) {
static CFAllocatorRef allocator = NULL;
if (!allocator) {
CFAllocatorContext context = {0, NULL, NULL, (void *)free,
NULL, myAlloc, myRealloc, myDealloc, NULL};
context.info = malloc(sizeof(int));
/* The info field points to an int which keeps */
/* track of the number of allocations/deallocations */
*(int *)(context.info) = 0;
allocator = CFAllocatorCreate(NULL, &context);
}
return allocator;
}
Is it required that the info fields first entry is an int ?
No.
Why would (void *) free be a suitable value for the release pointer (
CFRelease( CFRetain( myAllocator()))...) ?
The info field points to whatever you want; it's there for your custom
allocator to do its job. The retain and release functions (3rd and 4th
fields in the context) apply to the info field. In the above case, the
info field is a malloc'ed block; the retain func is set to nothing, and
the release func is set to free(), to free the block when the allocator
goes away. I think calling these retain/release is part of the
confusion...
Is the custom CFAllocator's code remembering the number of
allocations/deallocations in the first info int ?
Assuming you're talking about the custom allocator in the
"AllocatorExample" in the CoreFoundation examples folder: Yes.
Lets assume I am a short-lived factory that provides CF objects using
an equally (or ?) short-lived custom allocator. It would be
impractical to burden the user with the knowledge, that he should
retain a custom allocator. So my allocator will be released at the end
of the factory life but should only dealloc itself, when the number of
"free" calls have reached the number of "malloc" calls..
CF objects will retain and release the allocator; so if you create a
custom allocator, create CF objects with it, then release the
allocator, the allocator will eventually go away when the last CF
object allocated off of it is released.
If you also want to track other (non CF object) allocations with your
allocator, you certainly can use a counting scheme like the one in the
example does and release yourself when the number of allocations has
reached zero. One tricky thing is that you probably have to pass a
pointer to the allocator in to the allocate/deallocate functions, and
you can probably do that by putting a pointer to the allocator itself
in the info block. (Sheesh... This all is why we have ObjC and Cocoa!)
Ali
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.