

C++ Versus Objective-C   - TechNewb
http://www.mactech.com/articles/mactech/Vol.13/13.03/CandObjectiveCCompared/index.html

======
forrestthewoods
I hate Obj-C with a fiery passion. My single biggest issue with it is that it
simply does not make my life as a programmer any easier. On the other hand
when I work in C# I am constantly amazed at how damned easy the language and
the libraries make my life.

Not once when using Obj-C have I ever said, "Wow, that was so easy thanks to
Obj-C!!!" I am more likely to curse the heavens as to why the debugger can't
show me the contents of any basic container type.

Going forward my work will be as heavily cross-platform C++ as I can make it.
The UI may be done through platform native interface constructs, but
everything I can possibly make C++ I will.

~~~
alexbell
What you care to provide an example? Are you referring to not being able to
mouse over a var during debugging and having it displayed properly? I've never
minded having to use gdb to type out "po items", but can understand that if
you're used to mousing over and getting vars it would be annoying.

I don't disregard your perspective, mine is just exactly the opposite (I would
prefer ObjC/Cocoa to C++/<Framework of your choice>, no contest).

~~~
forrestthewoods
My perspective is one of a PC/console game background who works on iOS stuff
on the side. The transition from VisualStudio/C++ to Xcode/Obj-C is eye
stabbingly awful.

Obj-C can absolutely accomplish most anything that C++ can, but I don't think
the language makes of it easier. Once you've learned that GDB even exists and
figured out many of the strange syntax nuances it's passable, but in my
opinion not easier.

By comparison going from C++ to C#, Lua, or Python (my personal experiences)
is astonishingly easy. Not just easy at first but continuously surprising at
how many wonderful things you can do and how easy it is. As I said in my root
post not once have I ever said "holy shit Obj-C sure made this task easy!"

~~~
xsmasher
>Once you've learned that GDB even exists and figured out many of the strange
syntax nuances it's passable, but in my opinion not easier.

You can mouse over an NSArray or NSDictionary and see its size and contents.
You're not as familiar with the tools.

I have your same complaint, but about C++. I'm frustrated that I can't easily
see the contents of a std:set or std:map in xcode. I'd be thrilled to find out
if it's just a gap in my knowledge, though.

~~~
forrestthewoods
An NSMutableArray full of nothing but NSStrings will not display the string
values of those strings on either mouse over or the locals view. I can see the
number of strings but not what those strings actually are.

:(

------
wsc981
I've never really programmed in C++, but I have to say (as an iOS developer
who's programmed in Java, Basic, C# in the past) I love Objective-C. It's
really easy to write good, object-oriënted code in the language and it got so
much better with the release of iOS 5 and the new SDK, especially because of
ARC. I'm not sure if C++ has anything comparable to ARC.

~~~
albertzeyer
I wasn't sure what ARC is: It means Automatic Reference Counting.
<http://clang.llvm.org/docs/AutomaticReferenceCounting.html>

In C++, you have std::shared_ptr (or boost::shared_ptr and many others) which
do automatic reference counting (although you specify it explicitly that these
pointers have automatic reference counting; there is no way to simply enable
it for all raw pointer types).

------
Apocryphon
This is an interesting (though incredibly dated study) from an academic
standpoint because both languages are supersets of C and represent two
different lineages (Simula vs. Smalltalk). That said a more modern and useful
study might be a set of comparisons between Objective-C and Java, since they
are the current mobile dev languages of choice.

~~~
masklinn
> This is an interesting (though incredibly dated study) from an academic
> standpoint because both languages are supersets of C

Technically, C++ is not a superset of C. And each new release of either
language has them get more incompatible with one another.

------
runn1ng
The thing that this 1997 is missing is the retain - release mechanism, found
"only" in classes, that are derived from in NSObject, and still a key Obj-C
feature.

I don't really know when exactly was this added to NeXT/Cocoa API, but I think
it's important to note.

------
bdfh42
If this is a contest - then I declare "No Contest".

C++ is a standards based language available across multiple platforms and the
other one isn't.

~~~
Turing_Machine
Objective C is available anywhere GCC is available (i.e., essentially
everywhere).

~~~
drewcrawford
How I wish this were true. For example, lack of Objective-C and Foundation in
NaCl is my primary barrier to using it.

[https://developers.google.com/native-
client/faq#ProgrammingL...](https://developers.google.com/native-
client/faq#ProgrammingLanguageSupport)

~~~
wtallis
Is there any actual incompatibility that prevents building an Objective-C
runtime for NaCl, or is it simply a matter of ObjC not being included by
default?

~~~
drewcrawford
I've been thinking (warning: pure speculation ahead) that I could target my
binaries to LLVM IR and then use the highly-experimental PNaCL. But who knows
how long it will be before that is viable.

------
cplusoop
The lack of destructors and constructors makes Objective C miss an entire
galaxy of functionality. That the language authors and programmers don't
sorely miss this feature is a testimony to the limited understanding they have
of programming. Lack of destruct-when-I-leave-scope makes real exception
semantics impossible, and no "smart" objects that clean up after themselves
meaning it's impossible to create abstract data types with such limited
features. Programmers who don't miss these features I call "flat programmers"
because they are missing an entire dimension in their code. They are forever
having to understand the details of their implementations instead of being
able to package up functionality from initialization to destruction in
abstract terms. Don't bother trying to explain any of this to them. People
don't understand what they don't understand. They don't even know what they
are missing. But I suppose this is appropriate for Apple programmers who are
more concerned about which pixels appear in a drop down list box than the
overall job their program is attempting to do.

~~~
jronkone
This must be the 9001st time I read a post by a C++ programmer that doesn't
understand that the problem isn't that other languages don't have RAII. The
problem is that C++ doesn't have finally/unwind-protect and thus requires RAII
to approximate it.

~~~
makecheck
I would use RAII even if it weren't required for C++ exception safety. RAII is
_convenient_ and it allows you to write code that is smaller and more solid
than it would otherwise be (with or without a "finally").

~~~
masklinn
> RAII is convenient and it allows you to write code that is smaller and more
> solid than it would otherwise be (with or without a "finally").

You don't know what `unwind-protect` is now do you?

~~~
daemin
I've looked over what unwind-protect does and to me it doesn't do more than
what you can do with a custom RAII like class.

The key thing is that it acts like a wrapper around a try/catch/finally-like
block (including other forms of flow control), while allowing you to put
arbitrary code in the execute and cleanup portions. You would get the same
effect with RAII, most of it would be taken care of for you with the right
RAII classes, and if you needed custom code then just write a custom RAII like
class or be smart about handling it.

Although the C++ version wouldn't handle C's longjmp and also goto's. But if
you use them you're not exactly coding in C++ then.

~~~
makecheck
Not just longjmp and goto, but Objective-C's @throw.

As much as I'm a fan of RAII in C++, it really is a "pure C++" idiom. If a C++
class is needed in Objective-C code that can @throw an NSException, then the
C++ cleanup code really has to be invocable explicitly (because the destructor
might _not_ be called). For example:

    
    
      MyCPlusPlusObject object;
      @try
      {
        ...
      }
      @finally
      {
        object.cleanup();
      }

