Re: Include an executable without hard coding the path
Re: Include an executable without hard coding the path
- Subject: Re: Include an executable without hard coding the path
- From: Rick Schmidt <email@hidden>
- Date: Sat, 18 Jul 2009 21:34:09 -0500
Hmmmm... I had a lot of trouble trying to get those methods to work. I'm still learning much of this, I'll see what I can do about this in the future. I don't really have to worry about the file changing. Mostly the files I have to pass for this project are DNA sequence files, and the libraries go through and count all the bases, and figure out things like codon bias and should never write to the file. Thanks for pointing this out.
Rick
On Sat, Jul 18, 2009 at 7:24 PM, Quincey Morris
<email@hidden> wrote:
On Jul 18, 2009, at 16:56, Rick Schmidt wrote:
const char *sequenceFile2 = [sequenceFileNS UTF8String];
char *sequenceFile;
sequenceFile=const_cast< char*> (sequenceFile2);
Here I add to load a file file and pass it along as a char * to
another function. I couldn't find away to get a char * out of a
NSString object, only a const char * so I had to "cast away the
const-ness."
FWIW, there are a couple of issues here.
First, if whatever you're going to pass 'sequenceFile' to *really* doesn't change the string, casting away the constness should be fine. If you're not sure, you should use something like 'lengthOfBytesUsingEncoding:' along with 'getCString:maxLength:encoding:' instead, to get the UTF8 string in a buffer you provide.
Second, there is some uncertainly about the lifetime of the memory block returned by UTF8String (and related methods, like cStringUsingEncoding:). If you're not using garbage collection, it's autoreleased, so there's usually no problem (unless the place you're passing it to will try to keep it beyond the next pool drain without retaining it, which could easily be the case if you're passing it to a library of some kind).
If you're using GC, it's possible that the returned memory block behaves like an interior pointer -- it may disappear as soon as the underlying NSString is garbage collected, which may be sooner than you think.
Generally, if you're sending a C-string like this into the wild, it's safer to provide your own buffer and use 'getCString:maxLength:encoding:' or something equivalent.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden