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: Steve Cronin <email@hidden>
- Date: Sun, 14 Mar 2010 13:49:36 -0500
Folks;
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!
To Fritz: Thank-you for opening my eyes on this!
I had gotten it in my head that 'const' could not be used with objects!!
This is very useful to me!
Any thoughts on why the location of the single #include is so finicky?
Steve
On Mar 14, 2010, at 6:45 AM, Alexander Spohr wrote:
> .txt looks wrong.
> Why not create .h and .m and import the .h?
> Usually you #import, not #include in ObjC.
>
> .h
> extern NSString *gLeftBracket;
>
> .m
> NSString *gLeftBracket =@"<";
>
> atze
>
>
> Am 14.03.2010 um 06:47 schrieb Steve Cronin:
>
>> Folks;
>>
>> I have a dozen or so strings that I use over and over in various classes.
>> So here's what I've done
>>
>> I have a CommonStrings.txt file added to the project. It looks like this:
>> NSString *gLeftBracket =@"<";
>> NSString *gRightBracket =@">";
>>
>> If I #include this file somewhere in the project then I can use 'extern' in the classes/methods where I need one of these strings.
>> benefits:
>> one place for definition
>> type-ahead works - more efficient code construction
>> costs:
>> global-ness violates object-oriented principles
>> committed global overhead for entire project that doesn't benefit every class
>> however there are only ~20 of these
>> there is no inherent 'read-only' support (which is what I would prefer)
>>
>> On the whole I'm inclined to accept the costs for the benefits!
>>
>> Is there a better way to achieve the goal in ObjC2?
>>
>> 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…"
>>
>> Thanks for your time,
>> Steve_______________________________________________
>>
>> 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
>
_______________________________________________
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