Re: Frameworks and global variables
Re: Frameworks and global variables
- Subject: Re: Frameworks and global variables
- From: Art Isbell <email@hidden>
- Date: Thu, 12 Jul 2001 09:57:36 -1000
On Thursday, July 12, 2001, at 06:38 AM, Christian Mike wrote:
I am trying to access a global variable defined in a framework from an
application.
For example, I have a simple Cocoa framework that contains:
char *string[] = "Some String";
long value = 1234;
void Frame1Routine()
{
NSLog(@"Frame 1 message");
// code and stuff
}
Some general comments about programming style... Even in C
programs, many good arguments against global variables have been
made. Global constants aren't as bad, but because no const type
modifier is included in the above code, I assume these are
global variables.
I'm not aware of any extern'ed global variables in any of
Apple's Objective-C framework code. The one global constant I'm
aware of is the very handy NXApp. There's no need to use
extern'ed global variables, so why not use an object-oriented
Cocoa approach and avoid the pitfalls that Cocoa was designed to
eliminate?
When I see the above code described as Cocoa framework code,
it's pretty difficult to recognize it as such because Cocoa code
is object-oriented Objective-C or Java code. The above is pure
C code. I hope that new Cocoa programmers will take full
advantage of Cocoa's object-oriented design and avoid the use of
C strings (use NSStrings instead), global variables (make them
"class" or instance variables), C functions (make them methods
where it makes sense), etc. Objective-C doesn't have true class
variables, but some class variable features can be emulated by
declaring a global variable in a class implementation file and
then defining class (+) accessor methods.
Now in my application, I have added the framework to the
project. I know
that the framework is getting included properly, because I can call
Frame1Routine from my application, and the NSLog message is printed.
Now, if within my application I declare:
extern char *string;
extern long value;
and try to reference them from my application, it crashes with:
FinalApp.app has exited due to signal 11 (SIGSEGV).
In fact that same error happens even if I try to access those "global"
variables from within the Frame1Routine!
I don't know why this is happening, but if Apple should ever
decide to support Cocoa under Win32 again, you'll better
understand why global variables and extern declarations are
troublesome in the modern world of dynamically-linked libraries.
These problems can be avoided by simply making "string" and
"value" (hopefully with more descriptive names) instance or
class variables of a framework class. Then access them via
instance or class accessor methods.
As another piece of information, when I build the application,
I get the
following linker warning:
warning prebinding disabled because dependent library:
(HOME)/Library/Frameworks/Frame1.framework/Versions/A/Frame1 is
not prebound
I'm not familiar with prebinding's restrictions. Its
benefits include better performance, so I would think that you'd
want to avoid having prebinding disabled. Maybe it's not
possible to prebind when extern'ed global variables exist. I
can almost argue why this might be true :-)
Now, all of that said, the performance of Objective-C can be
inferior to that of pure C. So there may be times when
performance is such an issue that replacing certain
performance-critical Objective-C with pure C, NSStrings with C
strings, NSArrays with C arrays, value objects (e.g., NSNumber)
with primitive types (e.g., long int), etc. is essential. The
ability to improve performance in this way is a real advantage
of Objective-C programming. But I suggest doing this only
during code optimization, not during initial design and
implementation.
The advantages of true object-oriented design are
considerable, but object-oriented design has gotten an
unjustified black eye because of the experience of many C++
programmers whose "object-oriented" programs were really little
more than procedural programs written in a language with some
limited object-oriented constructs. So I encourage all Cocoa
programmers to give Objective-C and top-to-bottom
object-oriented design and implementation a real test. Most
who've done so have become real advocates.
Art Isbell
Apple iServices Technical Support
http://www.apple.com/iservices/webobjectssupport/
+1-808-591-0836