mikeash.com pyblog/friday-qa-2013-01-25-lets-build-nsobject.html comments

Aka Contacts - 2014-11-12 15:12:03

Wed, 12 Nov 2014 15:12:03 GMT

The is one of the best posts on the very basic of iPhone programming. Initially, I have no ideal on what NSObject does, but now I have a rough impression. Thanks for the great write up

mikeash - 2013-02-07 14:52:04

Thu, 07 Feb 2013 14:52:04 GMT

oneway is a modifier used for Distributed Objects. It says that the caller doesn't need to wait for the method to complete before proceeding, as it has no callee-visible side effects. It's an optimization, and one that doesn't make much difference these days, as DO isn't much used, and especially not in places where the latency of waiting for a call like this to complete would make a difference.

Ariel Feinerman - 2013-02-07 13:08:55

Thu, 07 Feb 2013 13:08:55 GMT

What is a oneway in the -release name ?

Ariel Feinerman - 2013-02-07 11:52:08

Thu, 07 Feb 2013 11:52:08 GMT

I use the -retainCount to see the memory leaks in objects with many levels of hierarchy for instance

Ariel Feinerman - 2013-02-07 11:42:50

Thu, 07 Feb 2013 11:42:50 GMT

Mike, you write that +allocWithZone: is deprecated but as far as I know for backward compatibility +alloc and -copy all call the allocWithZone: and copyWithZone:

mikeash - 2013-02-02 00:34:31

Sat, 02 Feb 2013 00:34:31 GMT

The perils of writing your own blog software. The <> is encoded in there, but for reasons as yet unknown to me, it needs to be double-encoded (e.g. &lt;). I extra encoding until I can figure out what's going on there. Thanks for the tip.

SSteve - 2013-02-01 22:24:05

Fri, 01 Feb 2013 22:24:05 GMT

generates a string of the form ,

You need some lt and gt encoding action inside that code element.

Kyle S - 2013-01-30 08:13:34

Wed, 30 Jan 2013 08:13:34 GMT

Perhaps there's hope yet of fusing `id` and `<NSObject>`…

George - 2013-01-29 16:42:28

Tue, 29 Jan 2013 16:42:28 GMT

Hey, thanks for sharing. It's super simple, and i got a clean understanding of what's going under the hood.

It'd be great to complement this with the ObjC's runtime code, though.

Thanks!

bbum - 2013-01-28 17:13:33

Mon, 28 Jan 2013 17:13:33 GMT

@chrisd NSObject was moved into the runtime because a number of system types well below Foundation (CF, really, as CF has a lot of stuff implemented in ObjC) are now instantiated as Objective-C objects in an opaque, but compatible with ARC, fashion.

SInce these types -- XPC and GCD related objects -- are in libSystem, the ObjC runtime now vends the required pieces directly such that libSystem can exploit these features without depending on CF or above.

See:

http://opensource.apple.com/source/libdispatch/libdispatch-228.18/os/object.h

chrisd - 2013-01-27 14:46:08

Sun, 27 Jan 2013 14:46:08 GMT

Looks like newer versions of the objc runtime source include NSObject's implementation. Not sure why... http://www.opensource.apple.com/source/objc4/objc4-532/runtime/NSObject.mm

Bryan - 2013-01-27 08:04:03

Sun, 27 Jan 2013 08:04:03 GMT

performSelector:withObject: should handle the case where the parameter is primitive type by unwrap NSNumber or NSValue and pass it to the actual implementation

Brad - 2013-01-26 22:20:24

Sat, 26 Jan 2013 22:20:24 GMT

"Why was retainCount ever made part of the interface?"

A pessimist might suggest that you have to go back to NeXT and start rounding up engineers if you want to find the guilty party for that decision. The snarky answer would be "It was the 90's. It seemed like a good idea at the time, just like the fashions did."

Jean-Daniel - 2013-01-25 23:19:12

Fri, 25 Jan 2013 23:19:12 GMT

@bob "retainCount reflects the number of retains and releases"

Unless this is a tagged pointer, a literal constant (@"string"), a cached NSMachPort returned with a retain count indefinite from -(id)initWirhPort:, a cached CFNumberRef, ….

So, yes this method may be useful for very specific case where you get the full control of the object implementation, and the object is not shared among thread, but I think all these exceptions are enough to call it non-deterministic, and unreliable.

jamie - 2013-01-25 22:33:51

Fri, 25 Jan 2013 22:33:51 GMT

Why was retainCount ever made part of the interface?

The only client that can make any use of it would be `self`, and it only cares that it's nonzero. It screams "No User-Serviceable Parts Inside"

bbum - 2013-01-25 22:05:46

Fri, 25 Jan 2013 22:05:46 GMT

@bob Fair enough and I agree; retainCount is very precise, but the value is, in practice, useless exactly because it lacks context.

And by the time you get the context -- the full history of retain/release/autorelease events, their thread, and their backtrace -- the value of the absolute retain count becomes redundant.

bob - 2013-01-25 21:24:14

Fri, 25 Jan 2013 21:24:14 GMT

@bbum: I didn't say that the value returned by retainCount was stable -- only that it reflects the number of retains and releases at that point (which may be inaccurate by the time it returns to you; but was accurate at some point).

The thing about autorelease is what confuses people about retainCount, but it does not affect what I said -- retainCount reflects the number of retains and releases, but autoreleases are not releases (they cause a release later), so if you retain and then autorelease, of course retainCount will be higher.

What I am trying to say is that retainCount "makes sense" if you knew all the retains and releases that happened to the object. So the problem with using retainCount is not with retainCount per se, but with the fact that you don't know all the retains and releases that various functions do (also concurrency is another problem). But a lot of times people treat retainCount it as if it's some completely arbitrary thing, that does not match retains and releases; and that's false.

bbum - 2013-01-25 21:00:24

Fri, 25 Jan 2013 21:00:24 GMT

And, yes, the `rand()` thing was an admittedly snarky joke. It isn't random (though it effectively was under GC, btw, as retainCount was short circuited to `return self;`).

bbum - 2013-01-25 20:59:09

Fri, 25 Jan 2013 20:59:09 GMT

@bob If you are implementing your own base class and control all implementations below it, retainCount is accurate as long as you don't have any concurrency and treat autorelease as a transitional state.

Beyond that, though, the value returned by retainCount is not useful exactly because it is both non-deterministic and, of course, the value may be completely "weird" due to implementation details of the system frameworks.

Even in the example you sight, the value you claim to be precise is not so precise. Claiming that "it is equal to 1" is specious exactly because that value may change immediately upon retrieval due to thread execution (and may effectively be in a transitional state due to autorelease).

In a concurrent environment, the only way to guarantee that retainCount's return value is stable and accurate is if you also put a lock/unlock around it that prevents any changes to the value (which means no retain/release until unlock).

@Colin Handling allocation errors across small allocations is a waste of time. If a program can't allocate 16 bytes, it is exceedingly likely that some other unhandled allocation failure has already left the app in a non-deterministic state. And, of course, most handlers would end up trying to allocate memory and failing.

(Handling *very large allocation* failures is definitely worth expending some thought on 32 bit systems. On 64 bit systems, the symptom will happily hand you back a many GB of address space only to let you page to death as you touch the allocation.)

bob - 2013-01-25 20:55:12

Fri, 25 Jan 2013 20:55:12 GMT

@Michael Bishop: well, there's an article right for you: Let's Build objc_msgSend http://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html

bob - 2013-01-25 20:11:26

Fri, 25 Jan 2013 20:11:26 GMT

@bbum: I am tired of this FUD about retainCount. NSObject's implementation of retainCount is perfectly deterministic, and is equal to 1 + the number of retains - the number of releases on that object. (Subclasses of course might have overridden these methods to do other things.) Period.

Yes, the number is *not useful* to the user. But that does not mean that it is random.

bob - 2013-01-25 19:59:13

Fri, 25 Jan 2013 19:59:13 GMT

@Iain Delaney: It is part of the Objective-C language. self and _cmd are implicit parameters to every method in Objective-C.

Michael Bishop - 2013-01-25 19:28:13

Fri, 25 Jan 2013 19:28:13 GMT

How would you implement objc_msgSend?

Chris L - 2013-01-25 19:11:00

Fri, 25 Jan 2013 19:11:00 GMT

I don't see why you should try to "gracefully" handle a failed memory allocation. Probably nothing is going to work right by the time that happens.

Colin - 2013-01-25 18:06:12

Fri, 25 Jan 2013 18:06:12 GMT

Thank you for this interesting post.

A question regarding the alloc method: Couldn't calloc failure (due to an out of memory condition) be handled gracefully like this:



    + (id)alloc

    {

        MAObject *obj = calloc(1, class_getInstanceSize(self));

        if (obj)

        {

            obj->isa = self;

            obj->retainCount = 1;

        }

        return obj;

    }

Or would it blow up anyway when returning NULL from alloc?

bbum - 2013-01-25 17:56:02

Fri, 25 Jan 2013 17:56:02 GMT

Your `retainCount` method is buggy. It should be:

    - (NSUInteger)retainCount
    {
        return rand();
     }

;-)

Iain Delaney - 2013-01-25 16:37:53

Fri, 25 Jan 2013 16:37:53 GMT

Don't you actually need to define 'self' somewhere? I'm a little fuzzy on this, but isn't 'self' part of NSObject, rather than being part of the Objective-C language?