Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the guaranteed lifecycle of -[NSString UTF8String]?

The docs vaguely say that it will stick around as long as needed, but when is it actually deallocated? When the original NSString is deallocated? When the current autorelease pool clears? Sometime else? Furthermore, when is it guaranteed to stay for, as opposed to the current implementation? If it stays for the lifetime of the NSString, will the same pointer be returned every time?

Thanks

like image 788
Jared Pochtar Avatar asked Jun 19 '10 04:06

Jared Pochtar


1 Answers

Update 30/11/2018

As David Dunham pointed out in comments, the Apple documentation has changed (the old link in my answer is now broken).

The Apple documentation now says:

This C string is a pointer to a structure inside the string object, which may have a lifetime shorter than the string object and will certainly not have a longer lifetime. Therefore, you should copy the C string if it needs to be stored outside of the memory context in which you use this property.

My original answer is now wrong in two parts.

My claim that the UTF8 string could possibly survive the deallocation of the NSString is explicitly denied by the current Apple documentation.

In the Apple docs "Autorelease context" has been replaced by "memory context". I'm not sure what that means exactly, but you probably should not trust the pointer after you have exited the scope in which it was acquired.

The Original Answer

The Apple documentation (broken link) says:

The returned C string is automatically freed just as a returned object would be released; you should copy the C string if it needs to store it outside of the autorelease context in which the C string is created.

That seems pretty non vague to me.

NB You shouldn't really worry about what the current implementation does. Implementations change

Extrapolating the above, the answers to your questions are probably:

but when is it actually deallocated?

When the autorelease pool is drained.

When the original NSString is deallocated?

No. The documentation implies you could alloc a string, take the UTF8String then release the string and the UTF8String would still be valid but be aware of this line from the Memory Management Rules:

A received object is normally guaranteed to remain valid within the method it was received ... although you must also take care if you modify an object from which you received another object.

"Modifying an object" might include releasing the NSString you got the UTF8 string from.

When the current autorelease pool clears?

That's what the docs say.

Sometime else?

No.

Furthermore, when is it guaranteed to stay for, as opposed to the current implementation?

If it's not documented, it's not guaranteed.

If it stays for the lifetime of the NSString, will the same pointer be returned every time?

I doubt it. Maybe for immutable strings, the UTF8 string is cached, but maybe not. Why not write some code to try it out? In any case, you can't rely on it in production code, nor in any situation where your NSString might really be an NSMutableString.

like image 164
JeremyP Avatar answered Oct 16 '22 12:10

JeremyP