int / float to NSString without using alloc?

Is there anyway to get int (or float) numbers into a NSString object without using alloc and a subsequent release?

int myInt = 25;
NSString *myString = [[NSString alloc] initWithFormat:@"%d",myInt];
... 
[myString release];

EDIT:

Thanks for the answers, I should have been a little more clear in the question, I am particularly interested in using this on the iPhone. As @chuck stated I could use a convenience method, but I was under the impression that I should be avoiding these where possib开发者_如何学Gole on the iPhone for memory / performance reasons. I could be wrong though.

gary

There's no way to create an NSString without creating it at some point. But you could use a convenience constructor so you don't have the burden of ownership.

NSString *myString = [NSString stringWithFormat:@"%d", myInt];

It will still be created and destroyed (as everything must be), but you don't have to do it yourself.

I could use a convenience method, but I was under the impression that I should be avoiding these where possible on the iPhone for memory / performance reasons.

The “performance reason” is the cost of autoreleasing an object. This was, at one time, expensive on an iPhone. (I don't know whether it still is.) The only alternative is explicitly allocating it and releasing it yourself. As others have pointed out, you can't have an object without having allocated it, and you mustn't allocate it without releasing it. You need both things to happen one way or another.

The memory reason is simply that an autoreleased object lasts longer—specifically, until the autorelease comes due. Autorelease many objects, and your memory usage will pile up; pile it up high enough, and SpringBoard will tell your app to knock it off (and/or just kill it). The solution is to make the objects not last so long, which means either (1) creating and draining your own autorelease pool around a known batch of objects or (2) managing the objects' lifetimes (that is, allocating and releasing them) yourself.

This latter reason is not specific to the iPhone—it affects the Mac as well, although our ceiling is higher: Macs have more short-term memory, plus virtual memory, so we can get away with more memory usage. Even so, we Mac programmers should also try not to waste memory, partly because paging hell wrecks one's day, and partly because we will get email from users if our apps sit too high in the Activity Monitor list.

NSString *mystring = [NSString stringWithFormat:@"Hello: %d",myint];

it should be autoreleased if you create it this way

i think the convention is that unless you see the word init or alloc in the method name then it should return an autoreleased object. i.e. the object is added to the current autorelease pool and flushed when the app advances to next stage in lifecycle

You want

NSString *aStr=[[NSNumber numberWithInt:myInt] stringValue];

It returns an autoreleased string.

You could use an NSMutableString (-appendFormat:) or a standard C-string. However, fundamentally, no, you're going to have to allocate memory somewhere.

Why not define a macro... something like

#define intString(i1) [[[NSString alloc] initWithFormat:@"%d",i1] autorelease];

put it in your prefix header.

Most of the time autorelease will have zero impact on your app's overall memory usage. You only need to be concerned with autorelease if you're accumulating many object instances. For example:

for (int i = 0; i < 1000; ++i)
{
    NSString* s = [NSString stringWithFormat:@"%d", i];
    ...
}

That example will accumulate at least 1000 different string instances before anything is released, which is not desirable. That's a situation where you would look for alternatives.

If you wanted to avoid creating a bunch of string instances you could use NSMutableString:

NSMutableString* s = [NSMutableString stringWithCapacity:20];
[s appendFormat:@"%d", 123];
...
[s setString:@""];
[s appendFormat:@"%d", 456];
...

It's questionable whether that's any faster than simply creating and releasing separate string instances, but that pattern may fit better with what you're trying to accomplish in your code.