In contrast to that, it probably takes years to really understand everything C++ has to offer. And that is talking about the language only, no frameworks or libraries included. Hence, I would say that you can not really compare Obj-C/Cocoa to C++, since the former is a framework and the latter is a language. (This is assuming that most people mean 'Objective-C and Cocoa' when they say 'Obj-C')
If you want to compare Objective-C and C++ on a language level though, you are comparing two very different languages. Objective-C strives for simplicity and readability, which makes some things easy and some things harder. C++ strives for world domination. There is nothing you can't do with C++, but there are just so many things you can do that figuring out how to 'properly' do stuff can be kind of horrid. Really, there are so many different styles and dialects of C++ that you could use and freely intertwine that defining the language proper is a real challenge. Note that this is not necessarily a bad thing. C++ has a lot of strengths and is increadibly malleable for many different applications. But putting all that flexibility in one language certainly makes that language a truly complex beast, where even reading it can be a real challenge even after years of using it.
Personally, I am a sucker for simplicity and elegance and I would take Obj-C over C++ any day. On the other hand, I have seen some situations where Obj-C's message passing was just too slow for my application and I had to drop back to C function calls in some areas. Also, Garbage Collection and even Reference Counting have a certain performance penalty that might make Obj-C unsuitable for, say, embedded applications.
There is nothing you can't do with C++
Complexity is not always directly proportional to the number of features supported.
Complexity is not always directly proportional
to the number of features supported.
C++ was designed with performance in mind. The main goal was to be as efficient as C and It means to not use any runtime.
Objective-C was designed to be source compatible with C and extends the language with a Smalltalk like syntax for OO. It uses a runtime which provides things like reflexion and GC.
Probably the most succinct description of the relative strengths of Objective C and C++. Objective C for GUIs, C++ for drivers and embedded development.
Objective-C is just C; there is no inherent performance penalty other than the dynamic dispatch of messages. In situations where that would actually be an issue, you'd be avoiding object-oriented features in C++ as well.
However, driver performance bottlenecks are typically in I/O throughput, not the language the driver was compiled in. The fact OS X drivers are written in a C++ subset likely has to do with the demands of device manufacturers coming over from MacOS 9, just like the existence of Carbon was to appease application developers like Adobe.
NeXTStep had DriverKit, a framework for writing drivers in Objective-C, and this was on 1990s-era PCs. Driver performance is I/O-bound and typically has little to do with the language the driver was compiled in.
Obviously, C++ being Turing complete these are all technically possible with C++. But in practice it would amount to "Greenspunning" the features of Objective C into C++.