Re: Newbie question: constants
Re: Newbie question: constants
- Subject: Re: Newbie question: constants
- From: Tim Hart <email@hidden>
- Date: Fri, 19 Nov 2004 00:57:59 -0600
The last 2 e-mails were written on a palm-OS device. I'm at home now,
and have done some research.
Apple's gcc (3.3) defines a switch '-fcoalesce'. The man page reads
this way:
-fcoalesce
Coalesce duplicated functions and data. The linker will
discard all
but one, saving space. Enabled by default. (APPLE ONLY)
Interestingly enough, it also defines this:
-fweak-coalesced
Use the new OS X "weak_definitions" section attribute for
coalesced
items. A single "normal" definition will be chosen by the
linker
over any number of weakly-coalesced ones. (APPLE ONLY)
This, and a simple test of my own - creating 2 source files that both
reference the same define in a separate header file seem to confirm the
following behavior:
In each '.o' file, the ObjC string defined in the header file occurs
only once, regardless of the number of times it is referenced in the
source file. In the executable, there is again only a single instance
of the defined string. This is a 'Foundation tool' project with default
settings from XCode 1.5, with ZeroLink turned off.
Adding the '-fno-coalesce' switch to the 'other c flags' did not
affect the output at all. Adding the -'fno-coalesce' switch to the
'other linker flags', oddly enough, also did not affect the output.
Exactly 1 instance of the string.
There is another switch - also enabled by default, which might be
affecting the above behavior: -fconstant-cfstrings. The man page reads
this way:
-fconstant-cfstrings
Enable the automatic creation of a CoreFoundation-type
constant
string whenever a special builtin
"__builtin__CFStringMakeCon-
stantString" is called on a literal string, and for "@"...""
liter-
als in Objective-C (thus overriding the
-fconstant-string-class
setting). This option will also be enabled if the
environment
variable "MACOSX_DEPLOYMENT_TARGET" exists and is set to
"10.2" or
greater. (APPLE ONLY)
I think these are all great things for a programmer to know - and I
have definitely learned something new.
For the newbie, though, I think this is information overload. For
constant declarations, there is a religious war - the above exchange
demonstrates such! If you're interested in the difference between the
two - by all means, learn them. If it's too much, don't sweat it -
either defines or global 'const' variables will solve your problem.
On Nov 18, 2004, at 11:34 PM, Wade Tregaskis wrote:
I'm not aware of any compiler flag at all which allows you to dictate
to
the compiler to *not* remove duplicate instances of static data. I do
plead
ignorance to the behavior of 'ld'.
There are some linkers that do not remove duplicates by default. I
believe gcc's linker fell or falls into this class, at some point in
time. I know it has been an issue in past. As I said, I think XCode
explicitly asks it to remove duplicates, but I am not certain.
In the case of simple types or NSStrings, my design is neither poor
nor
flat out wrong. There is no way to change the object 'myString' at
all. By
definition, any string declared at compile time with the @"" notation
is an
immutable string. Apple uses the same construct for their Cocoa
constants.
Defining an NSNumber object as a constant is a bit trickier.
The scenario I was referring to was using a mutable object - e.g.
NSNumber as you suggest - as a constant. I wasn't picking on your
method in particular, just stating it only works for truly immutable
objects.
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