In objective C what is the difference between id and void *? Thanks.
+3
A:
If a method has a return type of id you may return any Objective-C object.
void means, the method won't return anything.
void * is just a pointer. You won't be able to edit the content on the address the pointer points to.
Philipe Fatio
2009-08-20 05:53:00
As it applies to the return value of a method, mostly right. As it applies to declaring variables or arguments, not quite. And you can always cast a (void *) to a more specific type if you want to read/write the contents -- not that it is a good idea to do so.
bbum
2009-08-20 06:31:02
+1
A:
My understanding is that id represents a pointer to an object while void * can point to anything really, as long as you then cast it to the type you want to use it as
hhafez
2009-08-20 05:54:09
If you are casting from (void *) to some object type, including id, you are very likely doing it wrong. There are reasons to do so, but they are few, far between, and almost always indicative of a design flaw.
bbum
2009-08-20 06:27:01
quote "there are reasons to do so, but they are few,far between" true that. It depends on the situation. However I wouldn't make a blanket statement like "you are very likely doing it wrong" with out some context.
hhafez
2009-08-20 06:36:34
I would make a blanket statement; had to hunt down and fix too many damned bugs because of casting to the wrong type with void* in between. The one exception is callback based APIs that take a void* context argument whose contract states that the context will remain untouched between setting up the callback and receiving the callback.
bbum
2009-08-20 06:54:03
+4
A:
id is a pointer to an objective C object, where as void* is a pointer to anything.
id also turns off warnings related to calling unknown mthods, so for example:
[(id)obj doSomethingWeirdYouveNeverHeardOf];
will not give the usual warning about unknown methods. It will, of course, raise an exception at run time unless obj is nil or really does implement that method.
Often you should use NSObject* or id in preference to id, which at least confirms that the object returned is a Cocoa object, so you can safely use methods like retain/release/autorelease on it.
Peter N Lewis
2009-08-20 06:06:02
For method invocations, a target of type (id) will generate a warning if the targeted method has not been declared anywhere. Thus, in your example, doSomethingWeirdYouveNeverHeardOf would have had to have been declared somewhere for there not to be a warning.
bbum
2009-08-20 06:26:05
You're wuite right, a better example would be something like storagePolicy.
Peter N Lewis
2009-08-21 01:03:57
+2
A:
id is a pointer to an Objective-C object. void * is a pointer to anything. You could use void * instead of id, but it's not recommended because you'd never get compiler warnings for anything.
You may want to see stackoverflow.com/questions/466777/whats-the-difference-between-declaring-a-variable-id-and-nsobject and unixjunkie.blogspot.com/2008/03/id-vs-nsobject-vs-id.html.
Michael
2009-08-20 06:19:23
Not quite. (void *) typed variables cannot be the target of method invocations at all. It results in "warning: invalid receiver type 'void *'" from the compiler.
bbum
2009-08-20 06:24:43
@bbum: `void *` typed variables most definitely can be the target of method invocations- it's a warning, not an error. Not only that, you can do this: `int i = (int)@"Hello, string!";` and follow up with: `printf("Sending to an int: '%s'\n", [i UTF8String]);`. It's a warning, not an error (and not exactly recommended, nor portable). But the reason why you can do these things is all basic C.
johne
2009-08-22 22:17:16
Sorry. You are correct; it is a warning, not an error. I just treat warnings as errors always and everywhere.
bbum
2009-08-23 01:48:58
+35
A:
void * means "a reference to some random chunk o' memory with untyped/unknown contents"
id means "a reference to some random Objective-C object of unknown class"
There are additional semantic differences:
Under GC Only or GC Supported modes, the compiler will emit write barriers for references of type
id, but not for typevoid *. When declaring structures, this can be a critical difference. Declaring iVars likevoid *_superPrivateDoNotTouch;will cause premature reaping of objects if_superPrivateDoNotTouchis actually an object. Don't do that.attempting to invoke a method on a reference of
void *type will barf up a compiler warning.attempting to invoke a method on an
idtype will only warn if the method being called has not been declared in any of the@interfacedeclarations seen by the compiler.
Thus, one should never refer to an object as a void *. Similarly, one should avoid using an id typed variable to refer to an object. Use the most specific class typed reference you can. Even NSObject * is better than id because the compiler can, at the least, provide better validation of method invocations against that reference.
The one common and valid use of void * is as an opaque data reference that is passed through some other API.
Consider the sortedArrayUsingFunction: context: method of NSArray:
- (NSArray *)sortedArrayUsingFunction:(NSInteger (*)(id, id, void *))comparator context:(void *)context;
The sorting function would be declared as:
NSInteger mySortFunc(id left, id right, void *context) { ...; }
In this case, the NSArray merely passes whatever you pass in as the context argument to the method through as the context argument. It is an opaque hunk of pointer sized data, as far as NSArray is concerned, and you are free to use it for whatever purpose you want.
Without a closure type feature in the language, this is the only way to carry along a hunk of data with a function. Example; if you wanted mySortFunc() to conditionally sort as case sensitive or case insensitive, while also still being thread-safe, you would pass the is-case-sensitive indicator in the context, likely casting on the way in and way out.
Fragile and error prone, but the only way.
Blocks solve this -- Blocks are closures for C. They are available in Clang -- http://llvm.org/ and are pervasive in Snow Leopard (http://images.apple.com/macosx/technology/docs/GrandCentral%5FTB%5Fbrief%5F20090608.pdf).
bbum
2009-08-20 06:22:22
Do you know why, for example, in cocoa-touch, the UIView animation block "context" is a void pointer?
Mk12
2009-08-20 16:17:32
Additionally, I'm pretty sure that an `id` is assumed to respond to `-retain` and `-release`, whereas a `void*` is completely opaque to the callee. You can't pass an arbitrary pointer to `-performSelector:withObject:afterDelay:` (it retains the object), and you can't assume that `+[UIView beginAnimations:context:]` will retain the context (the animation delegate should maintain ownership of the context; UIKit retains the animation delegate).
tc.
2010-10-13 20:02:12
No assumptions can be made about what an `id` responds to. An `id` can easily refer to an instance of a class that does not inherent from `NSObject`. Practically speaking, though, your statement best matches real world behavior; you can't mix non-`<NSObject>` implementing classes with Foundation API and get very far, that is definitely for sure!
bbum
2010-10-13 22:42:37