Hi everyone. I'm new to Objective-C but I've been working with C++ for
years. I'm trying to understand how the selector mechanism works.
So far it seems to me that SEL is simply a wrapper for 'const char*', Obj-C
compiler maintains a table of all method name - method function pointer
pairs and pick
On 08/04/2009, at 1:34 PM, Daqi Pei wrote:
Hi everyone. I'm new to Objective-C but I've been working with C++ for
years. I'm trying to understand how the selector mechanism works.
So far it seems to me that SEL is simply a wrapper for 'const
char*', Obj-C
compiler maintains a table of all met
On 08/04/2009, at 4:08 PM, Graham Cox wrote:
Anyone knows why? Thanks
Incidentally, this document tells you all you need to know (and can
know) about the runtime:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Introduction/Introduction.html#/
/apple_ref/doc/u
On 7-Apr-09, at 11:34 PM, Daqi Pei wrote:
[myObj performSelector: (SEL)"someMethod"];
Oh, don't do that! ;-)
If you know the selector at compile time, you should use @selector()
for compile time checking.
Otherwise you should use the sel_getName() function to do the lookup
at runtime.
"Y
On Wed, Apr 8, 2009 at 3:17 AM, Mark Ritchie wrote:
>
> "You can not simply cast a C string to SEL." is from:
>
> http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ObjCRuntimeRef.pdf
>
> Note that while it's be convenient to cast SEL to char *, especially when
> debugging in
Thanks for all your answers. I was doing that basically trying to understand
how the
runtime works. Guess I've got what I need. Thanks again!
On Wed, Apr 8, 2009 at 3:21 PM, Sherm Pendley wrote:
> On Wed, Apr 8, 2009 at 3:17 AM, Mark Ritchie wrote:
>
>>
>> "You can not simply cast a C string to
64bit runtime selectors are not char* as far as I know.
In general, you should use NSSelectorFromString/NSStringFromSelector the
more low-level objc functions.
On Wed, Apr 8, 2009 at 9:21 AM, Sherm Pendley wrote:
> On Wed, Apr 8, 2009 at 3:17 AM, Mark Ritchie wrote:
>
> >
> > "You can not simply
A good way to understand the runtime is to read the sources:
http://www.opensource.apple.com/darwinsource/10.5.6/objc4-371.2/
Le 8 avr. 09 à 15:07, Daqi Pei a écrit :
Thanks for all your answers. I was doing that basically trying to
understand
how the
runtime works. Guess I've got what I ne
I remember I read that somewhere in an Apple document, but I don't
managed to find where, and I don't find any proof of that in the
sources.
Le 8 avr. 09 à 15:26, Julien Jalon a écrit :
64bit runtime selectors are not char* as far as I know.
In general, you should use NSSelectorFromString/
On Tue, Apr 7, 2009 at 11:34 PM, Daqi Pei wrote:
> Hi everyone. I'm new to Objective-C but I've been working with C++ for
> years. I'm trying to understand how the selector mechanism works.
> So far it seems to me that SEL is simply a wrapper for 'const char*', Obj-C
> compiler maintains a table o
On Apr 7, 2009, at 20:34 , Daqi Pei wrote:
Hi everyone. I'm new to Objective-C but I've been working with C++ for
years. I'm trying to understand how the selector mechanism works.
I think the best reference for that would be Brad Cox's original book
on Objective-C.
In short: selectors *a
On Apr 8, 2009, at 7:27 , Michael Ash wrote:
The runtime relies on this property for all kinds of things. By
passing in a naked C string, you're bypassing the uniquing mechanism,
and could easily end up with a string which has the same *contents*
but is not at the same address. This could break
12 matches
Mail list logo
