On 7/31/05 1:46 PM, John Stiles didst favor us with:
> I was never actually a fan of kCFAllocatorDefault. The biggest
> reason was that early versions of CarbonLib didn't even export that
> symbol, so you can't use it in code that targets pre-OS 9.0. That's
> a non- issue nowadays, but there's still no advantage to using the
> named "constant"--there is a disadvantage, however, because in this
> case it's not as efficient as a regular constant! The headers define
> it as
>
> /* This is a synonym for NULL, if you'd rather use a named constant. */
> CF_EXPORT const CFAllocatorRef kCFAllocatorDefault;
> Which means that every time you use it, the compiler goes and looks
> it up in memory instead of just sticking a zero into r3 like it
> could if you use NULL. Larger code size for no benefit.
> Neither of these issues are really a big deal--the cost of the load
> is one or two extra opcodes, and nobody supports Mac OS 8 any more.
> So nowadays you can use whichever technique you prefer. Personally
> I'll stick with the smaller code size, since I'm used to seeing NULL
> as the allocator anyway.
Just for the record, I tested this and there is no difference in code size.
Since there's no difference in the size or the performance of the resulting
code, and any difference in time to compile would be impossible to quantify
in a real application, I see no reason not to use the kCFAllocatorDefault
constant name.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
