On 7/31/05 1:46 PM, John Stiles didst favor us with:
> If I were writing the framework/universal headers, that would have been
> my choice.
> And for the purist/pedantic among us, you could always do something
> along the lines of
>
> #if _cplusplus
> const CFAllocatorRef kCFAllocatorDefault = NULL;
> #else
> #define kMyCFAllocatorDefault NULL
If I were going to use a macro, I'd define it like this:
#define kMyCFAllocatorDefault ((CFAllocatorRef)NULL)
This way you can't accidentally pass kMyCFAllocatorDefault in a parameter
that doesn't take a CFAllocatorRef. I know that's not likely to happen here,
but I'm a big advocate of consistently using good, defensive programming
practices as opposed to saying "Well, in *this* case I can just do [some
shortcut]."
> #endif
>
> In straight C, the global const here would use up space for every file
> that #includes the header, requiring the use of #define; in C++, the
> compiler does not use storage for this sort of constant global. (That's
> one of the things that makes it hard to write straight C code without
> using macros all over the place. C does let you [ab]use enum for
> constant global integral values, but that's the best you've got.)
>
>
> Kevin Grant wrote:
>
>> It's interesting how it's defined - but NULL still works, doesn't it?
>> Why not "#define kMyCFAllocatorDefault NULL" and use that constant to
>> get the best of both (aside from purist reasons of not liking #define)?
>>
>> Kevin G.
>>
>>> <offtopic>
>>> 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.
>>> </offtopic>
I find code to be more readable with named constants. *You* may know exactly
what NULL represents as a parameter, but someone else reading your code may
not. With named constants that's never an issue. Named constants for NULL,
true, and false make code a lot easier to read IMO. Personally I think it's
also a matter of consideration when posting code here. I see code snippets
here from people who use NULL in various places, and most the time I don't
remember what that parameter is until I look it up. When I post code here I
want to make it as easy as possible for people to help me.
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
