Re: Newbie question: constants
Re: Newbie question: constants
- Subject: Re: Newbie question: constants
- From: Wade Tregaskis <email@hidden>
- Date: Fri, 19 Nov 2004 14:33:17 +1100
I'm coming from a heavy Java background, with little experience in C
or C++,
so I'm sure this is a stupid question. What's the best way to create
constants, both public (available to all classes) and private
(available to
only the class in which it was declared)? Specifically object constants
(i.e. NSString or NSArray), but also primitives like int as well.
Well, there's some argument over atomic values (ints, reals, etc) in
the C/C++ world... some people argue for a variable constant, others
for defines. It basically boils down to a pretty trivial performance
difference between referencing from memory and performing operations
immediately (i.e. the value embedded in the instruction itself). On
the PPC architecture you can generally only use 16-bit immediate
integer values, and there is no support for floating point immediates
(afaik). There's a significant performance gain to be had with using
immediates (defines) over memory references (const variables) on the
PPC (maybe not so on the i386), but I would wager any good compiler
will optimise the const variable case into the immediate case anyway.
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. :)
[[ 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. Best to define all variables in implementation files anyway, for
safety and good design (information hiding). ]]
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. Alternatively, you can adopt the more common
practice of declaring your NSString's as global variables in your
implementation, then placing extern's to them in your header. E.g.
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).
Be careful with trying to treat mutable objects as literally constant,
e.g. NSMutableString... they're not explicitly constant, and so you
have to be very careful your design doesn't accidentally change them at
any point (i.e. by passing them unknowingly to a 3rd party library
which pokes at them). Generally you should avoid constant mutable
objects - implement some sort of getter function or method instead,
which could return a mutable copy of a immutable reference version, or
somesuch. It's very rare that you'll need a mutable "constant" that
you need to treat as immutable - indeed, if you find such a need it
usually indicates a design flaw in the class in question.
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...
Also note that string constants declared using CFSTR() or as
compile-time variables are of a special NSString subclass which makes
them ignore any final release call (or something like that) - i.e. they
can't be deallocated (although you should still retain/release them
like a good citizen, just like a normal NSString). This can cause
nightmares when debugging, where superfluous releases don't cause any
obvious error in your test cases... yep, this one caught me out just
recently, thus why I mention it. :)
Wade Tregaskis (AIM, Yahoo & Skype: wadetregaskis, ICQ: 40056898, MSN &
email: email@hidden, Jabber:
email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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