Re: #include CommonStrings.txt - 'no such file' error
Re: #include CommonStrings.txt - 'no such file' error
- Subject: Re: #include CommonStrings.txt - 'no such file' error
- From: Fritz Anderson <email@hidden>
- Date: Sun, 14 Mar 2010 14:24:42 -0500
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 (email@hidden)
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:
This email sent to email@hidden