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: Bob Ippolito <email@hidden>
- Date: Thu, 27 Oct 2005 17:03:07 -0700
On Oct 27, 2005, at 3:01 PM, Brian Stern wrote:
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.
Wrong! Remember that Objective-C is a superset of C:
static __inline__ BOOL iseol(char *p) { return ... };
(see the definition of FOUNDATION_STATIC_INLINE in <Foundation/
NSObjCRuntime.h>, for example).
MIN, MAX, ABS should be inline functions, not macros.
MIN/MAX/ABS can't be functions because they need to be polymorphic
(int/float/double/etc.) and you don't get that in C or Objective-C
except with 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.
enums are pretty much the way to do it, as far as I can tell.
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.
Having constant NSString objects at file scope shouldn't really do
you anything useful.. all of the strings should end up in a constant
string table in a single compilation unit, so #define and static
NSString* should have the same net effect. If you are doing it at
file scope, you're just making the same optimization that the
compiler is doing anyway and might even end up making it worse
(though probably not measurably).
For those cases specifically I'd just type out the constant string.
Seems kinda silly to say "comma" when you can just put one in there
literally.
-bob
_______________________________________________
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