On 14 Mar 2010, at 1:49 PM, Steve Cronin wrote:
> To Alexander: On the suggestion of using .m and .h files:
>
> If I use a single #include somewhere as shown below then I can within any
> method use
>
> extern NSString *gLeftBracket
>
> this allows other programmers to see immediately that it is defined elsewhere
> and I need not burden the entire class with the overhead #import the entire
> set of these common strings. It seems your approach require that I expose a
> given class to the entirety of the strings declared in the .m file. I
> believe my solution allows a more fine grained usage of these strings….
> Please enlighten me if I am incorrect!
Perhaps you misconceive the effect of extern declarations.
It is proposed that you define your constants (no extern) in an .m file — any
.m file — which you won't have to #include anywhere else, because as an .m file
it'll be compiled in its own right. It is then proposed that you have a .h file
(call it MyAppGlobals.h) containing just this:
extern NSString * const gLeftBracket;
extern NSString * const gRightBracket;
// etc.
In any .m file in which you use any of those constants, you #import
"MyAppGlobals.h". The "extern" keyword doesn't just tell other programmers that
the symbols are defined and allocated elsewhere; it tells the _compiler_ that
they are, and what type they are. This is not a burden on anything; the
compiler and linker _need_ that information. You won't be re-reading the
strings themselves, only the information that they exist.
As for overhead in reading MyAppGlobals.h or parsing what may be a lot of
symbols, there isn't any worth worrying about. If the file is frequently used,
the file system will cache it in memory. We're talking about a second over the
course of a multi-minute build. You'd see more difference from whether the
machine had been recently rebooted, Xcode recently started, or what other
processes are running.
If MyAppGlobals.h is stable, you can #import it into your .pch.
You mention #include. Use #import if at all possible. It takes care of #include
loops for you.
> But here's my real question:
> It appears that I cannot put the one and only #include CommonStrings.txt just
> anywhere in the project.
> Some locations work fine others result in a 'CommonStrings.tx.' - no such
> file error.
> I'm just cutting and pasting the #include statement - so I'm not munging the
> statement.
> I cannot see any rhyme or reason on where it works and where it doesn't…
> Can someone clarify this for me?
> Kochan ObjC2 p209 clearly states, "…variable must be defined someplace among
> your source files…"
I'm not sure what you mean by this. Do you mean that the compiler issues a
file-not-found error for "CommonStrings.tx.", and shows you a line in your
source that explicitly says:
#include "CommonStrings.txt"
? Try Build > Preprocess on the #including file, and see what the line looks
like net of preprocessing. There may be other factors, like the relative
directories of the #including source and the .txt file. I wouldn't be surprised
if files with conventional source-file extensions got special-case searching
treatment that other file types didn't.
I'd bet switching to a more conventional #import/#include strategy will fix the
anomaly, and you might want to forget about it then.
— F
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
