Re: Accessor macros used by GNUstep but not Cocoa?
Re: Accessor macros used by GNUstep but not Cocoa?
- Subject: Re: Accessor macros used by GNUstep but not Cocoa?
- From: Brian Stern <email@hidden>
- Date: Thu, 27 Oct 2005 18:01:20 -0400
At 11:12 AM -0500 10/27/05, Scott Thompson wrote:
>> I was working on creating some accessor macros when I happily found
>> that GNUstep (GNUstep.h - ASSIGN is exactly what I was thinking)
>> has these already. Then I became curious, is there any particular
>> reason that Apple hasn't adopted this approach with Cocoa? (i.e. is
>> there a technical reason or is it just a stylistic difference? The
>> macro approach seems more flexible.)
>
>It could be because "macro languages" are EVILĀ :-)
I must say that my Cocoa projects use the preprocessor more than my C++
projects.
1) For instance, no inline functions leads one back to the old days of C
programming. From a current project:
#define iseol(p) (0 != (((p)[0]=='\n') || ((p)[0]=='\r' && (p)[1]=='\n') ||
((p)[0]=='\r')))
#define iscrlf(p) (0 != (((p)[0]=='\r' && (p)[1]=='\n')))
#define iscr(p) (0 != ((p)[0]=='\r'))
#define islf(p) (0 != ((p)[0]=='\n'))
While I realize that these could be simple C functions rather than macros I
do them this way for the improved performance. I suspect this is common
practice in Objective-C apps.
MIN, MAX, ABS should be inline functions, not macros.
2) gcc, or Objective-C doesn't seem to do const int in a useful way so
constants are either macros or enums or something else.
3) Also, I like to use named constants where possible. For constant
strings I find myself doing this at file scope:
#define comma @","
#define colon @":"
#define starcomma @"*, "
#define commaspace @", "
and then using the named constants in the code. I'm unclear on whether
this is exactly the same as having constant NSString objects at file scope:
static NSString* comma = @",";
I think there are some wierdnesses if you try to put a constant string in a
header file, but those #defines could go in a header file for use
throughout the project without any problems.
At any rate I definitely find myself using the preprocessor more with Cocoa
than with C++.
--
Brian Stern
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden