Take the 2-minute tour ×

There are methods in Cocoa classes that accept an address of a pointer. Most commonly the argument is address of future NSError * object in CoreData validation methods (among others). This way it is possible to put custom or owned object into the place of the address that given argument points to.

My question is: why can't we do that with simple pointer arguments? E.g. let's say I have a method:

- (void)addObject:(id)someObject toArray:(NSMutableArray *)array;

I can easily pass the mutable array as second argument, call addObject: on it and after the method call the array will be modified. Why is this not done with NSError * objects? Are pointers passed to methods are defined as const by default? Is this to avoid accessing NULL?

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

Why is this not done with NSError * objects?

Because there's no such thing as an NSMutableError. Your example works because you can modify the contents of the array without modifying the pointer to the array itself. However, since NSError instances are immutable, you cannot modify an NSError. As such, you must necessarily create a new error object. And if you want to return that error object along with some other piece of data, at least one of those must be done via an out-parameter (such as an NSError **).

Are pointers passed to methods are defined as const by default?

Nope. Inside that method you're welcome to do this:

  someObject = somethingElse;
  [array addObject:someObject];

What's important to remember here is that you're only changing a pointer in a slot in memory. The memory slot corresponding to someObject is just a space on the stack, and you're changing the contents of that space to have a value that points to a different allocated object than the one you were given.

Is this to avoid accessing NULL?

Any NULL protection you need must be done yourself.

share|improve this answer
NULL protection is built into objective-C quite a bit, and its nice. I like to code knowing that [array count] == 0 if array is NULL or empty. Ruby and many other languages blow up at this point, and you need extra code to deal with null in many instances. –  Tom Andersen Jun 4 '12 at 15:37
@TomAndersen There's a difference between passing nil and messaging nil. [nil addObject:blah] has no effect. [array addObject:nil] will blow up in your face. –  Dave DeLong Jun 4 '12 at 15:42
add comment

It's because the NSError class does not define any way to modify instances after creation. The pointer itself is mutable, but an NSError is not.

share|improve this answer
add comment

They are all plain C pointers. They are not const unless you make them const. Const pointers are not a good thing to use in most situations in objective-C, or even often plain C. Const pointers are a subtle concept, and the complexities of the meaning and syntax don't mesh well with the Objective-C style of programming. Forgetting they exist is likely a good first approximation.

Example: NSArray and NSMutableArray - we would not need an NSArray class if const worked 'correctly' - but it can't due to the design of C.

** - For NSError, etc., the idea is to create an NSError, not alter the one you have passed in. In other words, you need a pointer to a pointer to be able to create an instance (i.e. change the actual object).

share|improve this answer
add comment

Your Answer


