HN2new | past | comments | ask | show | jobs | submitlogin

I think putting it that way exaggerates the differences a bit. The message doesn't really have to be "interpreted" in any meaningful way AFAIK. A message consists of a selector (essentially a method name) and a receiver, then whatever other arguments the method will take. The runtime looks up the selector in the receiver's method table, much like with C++ virtual methods, and then jumps to the implementation it finds. There is a little more fanciness (some method caching, and support for nil receivers), but I don't feel like it's hugely dissimilar from virtual methods.

For anyone interested, here's a good analysis of Objective-C's message dispatch machinery: http://blog.zhengdong.me/2013/07/18/a-look-under-the-hood-of...



The vtable is a flat structure with known layout in C++. In Objective-C, it's a hash table (with precomputed hashes and lots of other tricks—but it's still fundamentally a hash table). There's a big difference between the two.


There's a big difference between the data structures, yes, but the basic logic for message sends is still pretty similar. They both boil down to a simple lookup in a data structure and a jump. Would you really characterize the difference between a vtable and a hash table as "you actually pass a message, that first must be interpreted" in the case of a hash table?


I think the biggest issue is that in a vtable you jump directly to the method by index, and with objc_msgsend it looks up a string in a hash table.

Mostly the difference is ints vs. strings in my opinion.

As well in C++ if you don't mark your method virtual you can bypass all the vtable crap.

I love ObjC but method resolution is far more expensive than in C++, especially non-virtual methods.


Method selectors in Obj-C don't have to be strings, as long as you can turn a string into one occasionally.

You do still need to do a hash lookup to get the method implementation, since the selector table changes at runtime and objects have to safely respond to unhandled selectors and all that.


I meant string as in char* not NSString, selectors specifically the SEL datatype are strings

They certainly don't have to be, however, they are.

    SEL selector = @selector(applicationDidBecomeActive:);
    printf("%s",(char*)(void*)selector);
    // Prints applicationDidBecomeActive:




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: