Re: Newbie question: constants
Re: Newbie question: constants
- Subject: Re: Newbie question: constants
- From: Tim Hart <email@hidden>
- Date: Thu, 18 Nov 2004 22:49 -0600
Woah - I'll agree with most points Wade mentioned. I'll point out my
disagreements below, but to summarize:
One opyion is to place the following in a header file if "public" or a .m
file if private:
#define SOME_INT 32
#define myString @"Some String"
OR
If public, place the following in a header file:
extern const int kSomeInt;
extern NSString* const kSomeString;
Regardless, place the following in a source file, outside any class or
function definitions:
const int kSomeInt = 34;
NSString* const kSomeString = @"my string";
>Bottom line is that, after carefully stepping through the minefield of
>this particular religious argument, it makes no difference whether you
>use define or const variables. Pick your favourite. :)
Eh. I think there is *some* difference, but I'll agree that in most
circumstances the difference is negligible. A dedicated programmer owes it
to himself to understand those differences.
>
>[[ As an aside, I'm pretty sure XCode is setup by default to remove
>duplicate definitions of constants that might arise from declaring them
>in your header rather than your implementation... but don't hold me to
>that.
Its a gcc thing, not an XCode thing. When gcc compiles a source file to an object ( .o) file,
all duplicate references to a constant data value are removed (i.e., the data section of the
object file holds only one instance of @"myString", regardless of how many times @"myString"
occured in the post-processed compilation unit. I do not know if the linker removes duplicate
data constants. Anyone?
>With non-atomic types such as NSString's, you can't so easily use
>defines, although it is possible in some cases - e.g. CFSTR("xxx") will
>return the constant NSString @"xxx", so you can #define myString
>CFSTR("zzz"), I think.
#define MY_STRING @"FRED"
... works just fine.
>Implementation.m:
> NSString *myString = @"Woot!";
>
>Header.h:
> extern NSString *myString;
>
>This way you don't explicitly define the value for myString prior to
>runtime, so people won't be so tempted to abuse the knowledge (not that
>they usually would, but nonetheless, hiding the actual value is good
>design).
<snip>
>You unfortunately can't doing any definitions like "const NSString
>*myString = ...", because you then can't use that NSString directly in
>any AppKit or Foundation (or any other framework, really) - they all
>expect non-const arguments, so you'll get compile-time errors... this
>is a bit of a shame, but there's probably reasonable arguments both for
>and against using "const" more rigourously...
NSString* const kMyString = @"some string";
works just fine in these cases. It's worth your while to learn how 'const'
works. Where it is positioned in a declaration is important. I'm afraid i'm
lousy at explaining how it works. Anyone?
_______________________________________________
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