Re: How different is obj c from c++?

Lynn McGuire <lmc@winsim.com> wrote:


  That article concentrates mostly on minutia and skips the most *important*
differences between the two languages.

  Where Objective-C shines:

  - Objective-C has full runtime introspection and reflection.
For example, you can take an anonymous object (ie. an object from
which you know *absolutely nothing*, ie. you don't have any kind of
class declaration) and check if it, for example, has a method with
a certain signature, and then call that method if that's so. (C++
has basically zero support for this.) You can likewise determine at
runtime if an object is of a certain type or derived from it (similar
to C++'s dynamic_cast), is exactly of a certain type, implements a
certain interface, or contains a certain member variable.

  - As a consequence of the above, you can call a method (well,
technically speaking "send a message") whose signature has been
created at runtime (ie. was not determined at compile time).
(In principle it could be possible, for example, to have a class
definition as a text file which is parsed and interpreted at runtime.)
Yet calling Objective-C methods is suprisingly efficient (constructing
a selector eg. from a string is not efficient, but once you have the
selector, sending it to an object is surprisingly efficient).
According to my tests calling an Objective-C method is only about
6 times slower than calling a raw C function, which is impressive
considering the amount of dynamicity involved.

  - Likewise because of the above you can create an object of the same
type as another object, without having to know what that type actually
is (iow. even if you have a completely anonymous object). In C++ you have
to know an object's exact type in order to create another one of the same.

  - "Method pointers" are much easier and versatile in Objective-C than
in C++. (Basically, a "method pointer" doesn't need to know which class
it's for, and in fact the same method can be called using such a "pointer"
for completely unrelated classes. This alongside anonymous object pointers
makes it quite versatile and useful. All this is because you are not,
technically speaking, handling a "pointer" but a "message", and the
signature of this "message" is not dependent on any class.)

  Where Objective-C sucks:

  - No RAII. Enough said.
  (On the Mac OS X platform you can use a limited form of garbage collection
that takes care of eventually freeing objects. However, this feature is not
available on all platforms, eg. on the iPhone. Regardless, RAII is useful
for more than just memory management.)

  - No constructors.
  (There are "constructors" in Objective-C classes, but they are a meta
convention, not something imposed or handled by the language itself.
These constructors do not get automatically called, like in C++, but have
to be called explicitly, and there's no way to ensure that a certain
constructor is called when the object is created. This can be annoying
when creating a derived class, because there's simply no way of creating
a constructor for it that will surely be called when the object is
created.)

  - There kind of is a destructor that always gets called, but even then
it's really also a meta convention rather than a language feature. (It gets
called because all objects are/should be derived from a common base class
NSObject which calls this "destructor" when its reference counter gets to
zero, or when the garbage collector wants to free it. However, the lack of
automation can be seen in that in your destructor implementation you have
to manually call the destructor of the superclass. If you don't, you have
probably a leak.)

  - Because of all the above, and because objects cannot be handled by
value, C++-style "smart pointers" which would handle reference counting
of objects automatically are just not possible.

  - No private methods.
  (Methods can be "private by convention" in that they do not have to be
declared alongside the class declaration. However, nothing stops something
from calling this "private" method by simply sending the object the message
with the proper signature.)

  - No abstract classes. (In C++ parlance this means that there's no support
for pure virtual functions, ie. classes that cannot be instantiated directly
but have to be specialized.)

  - No inner classes or types. Everything goes to the global namespace.

  - No templates or "generics" of any kind. (Generic object data containers
are possible, but they can only contain anonymous pointers, which means that
you always have to downcast. Obviously it's not possible to have generic
data containers for basic types.)

  - No way of calling the "super super" class from a method. (It's a question
of discussion whether this is a good or a bad thing. I consider it a bad
thing.)

  - (Lack of multiple inheritance was already mentioned in the article.)