Ask Slashdot: Which Classic OOP Compiled Language: Objective-C Or C++?

Qbertino writes: I've been trying to pick up a classic, object-oriented, compiled language since the early 90s, but have never gotten around to it. C++ was always on my radar, but I'm a little torn to-and-fro with Objective-C. Objective-C is the obvious choice if you also want to make money developing for Mac OS X, but for the stuff I want to do, both languages would suffice on all platforms. I do want to start out on x86 Linux, though, and also use it as my main development platform. Yes, I know quite a few other languages, but I want to get into a widespread compiled language that has good ties into FOSS. Both Objective-C and C++ fit that bill. What do you recommend? How do these two programming languages compare with each other, and how easy is cross-platform development in either? (Primarily GUI-free, "headless" applications.)

Comments

C++ is the only logically option

[ameoba]

C++ is still very much a living, actively developed language. There's a lot of people using it for modern projects. It's well supported under pretty much all modern operating systems & you have excellent tools available under Linux.

There's not a lot of reason to pick up Objective C unless you plan on targeting Apple. It's pretty much a dead language everywhere else, outside of a few niche projects.

Re:C++ is the only logically option

[Anonymous Coward]

Apple's statements in support of Swift make it sound like it's Apple's intention for Objective-C to be a dead language in their eco-system as well.

C++, C++, C++

[Anonymous Coward]

C++ is darn-near universal. It is everywhere and everyone uses it for everything.

Objective-C is an alternative language used, supported, and pushed by exactly one vendor. It only even exists because of the hipster mentality to "be different" just for the sake of being different with no real other point.

I don't see how this can possibly be a difficult decision.

Learn C++, and if you find yourself needing to dabble in Objective-C for some Apple device, no problem there. Doing the reverse would be more challenging and would limit your skills.

Re:c++?

[menkhaura]

Even for non-GUI work, Qt is a blessing if you want to do cross-platform programming. The library does a lot, ranging from database access to network programming, all in a very well documented and well thought out API.

Good luck.

Objective-C is a lot of work

[OrangeTide]

Unless you're using Apple's base libraries. Implementing a new Base Library is hard, I've gotten a tiny subset working on my own to see just what is involved. I wouldn't recommend writing the full thing unless you have a burning desire to do it. Porting GNUstep Base Library to various platforms is possible, and has already been ported pretty widely. You'll have to bundle LGPL libraries with your application if you plan to distribute binaries, depending on your application that can make Obj-C a non-starter.

I use C everywhere, and never C++. C is not the easiest thing to do, but putting together portable frameworks for C is less work than doing the same for Objective-C. (at least in my personal experience, your mileage may vary). C isn't an object oriented language, in that it doesn't do anything special to make that work. But there are OO toolkits for C, with varying degrees of horribleness. A classic is Xt (X Toolkit) and Xaw(X Athena Widgets), which is not terribly C99 friendly anymore. But it does permit limited object-oriented hierarchies. GObject (GTK+) is another option for C, I'm not a fan of it, but it's not obsolete unlike the Xtk/Athena example I mentioned.

What confuses me about your question is why are you only asking about C++ or Objective-C? There is Free Pascal (Delphi clone) and D. (D is very good, I highly recommend that over Obj-C). There are probably a lot of other options out there that would suit your initial criteria, especially surprising is you didn't mention Java. It's very good example of OO, perhaps OO taken to the extreme, but it's fairly clean. (Obj-C is a little hacky, but thats it's charm and power)

C++ is probably a little bit better

[Chalnoth]

There really isn't all that much difference, so that once you get comfortable with one you should be able to switch to the other without much difficulty if you need to. But I'd lean towards C++ because the tools are more mature.

Two other tips:

1. Use Clang (part of LLVM) as your compiler. The error messages are vastly easier to interpret, which should cut down on both learning and development time. Note that Clang supports both Objective C and C++.

2. If you do go for C++, make sure to start learning on C++11 or C++14. C++11 significantly changes quite a lot about the language, and if you start with older C++ books, you'll have to unlearn a lot of stuff if you want to develop modern C++. C++14 has mostly just minor fixes to C++11.

Even Apple is abandoning Objective-C

[msobkow]

Apple has made it clear their development future lies in Swift, not Objective-C.

That means you're choosing between a popular, well supported language and a dead end.

The choice should be obvious.

C++ - but look at C# as well

[slincolne]

I'll admit I haven't seen much of Objective C (apart from on OSX) - while C++ is pretty much available on anything and anywhere. However I'd also recommend having a look at C#.

If you are not allergic to Microsoft products it's got a lot to recommend it:

Good frameworks

Available on Windows, OSX & Linux

Cross-platform tools like Xamarin (which as an interesting ecosystem for cross-platform mobile apps)

C++ important on Apple too

[perpenso]

There's not a lot of reason to pick up Objective C unless you plan on targeting Apple.

C++ is also important when targeting Apple. Objective-C is the language of the Cocoa API (Mac OS X and iOS), however there is no need to use it beyond code that makes Cocoa based system calls. And getting C++ and Objective-C code to call each other is trivial.

Personally I recommend separating UI and platform (OS) specific code from an app's core functionality and implementing the UI/platform-specific code in whatever the native language for the platform is and implementing the core code in C/C++. This leaves the core code portable, ready to target other platforms. I have iOS apps where the core code can be compiled in a console Linux environment and exercised by various scripts (regression testing) and in a random manner (fuzzing).

Re:c++?

[Anonymous Coward]

Another plug for Qt:

If you are new to C++, Qt makes it very easy to write code without too many trips to Google. QString class is my favorite example of this. It's pretty easy to figure out how to split a string on a comma with QString. How do you do it with std::string? If your answer wasn't "use boost", you found some chunk of code on Stack Overflow, didn't you?

The downside to this aspect of Qt is that it can make transitioning into non-Qt C++ development a bit of a challenge.

Re:c++?

[Anonymous Coward]

Objective-C is an ugly, clunky language, and the only reason Apple uses it is to intentionally make your code incompatible with other platforms.

Actually, they use it for its dynamic binding and loading, but don't let facts get in the way of your FUD!

Re:c++?

[TechyImmigrant]

Objective-C is an ugly, clunky language, and the only reason Apple uses it is to intentionally make your code incompatible with other platforms.

Actually, they use it for its dynamic binding and loading, but don't let facts get in the way of your FUD!

That and C++ was horribly immature at a time when Objective-C was not and the Next guys were developing NextStep.

Re:c++?

[Jeeeb]

Objective-C is an ugly, clunky language, and the only reason Apple uses it is to intentionally make your code incompatible with other platforms.

I'm not a particular fan of Objective-C either but this is just wrong. Apple inherited Objective-C when they bought NextStep and used it as the foundation of OS X. OS-X got its start in life as a partial rewrite of the NS shell and the addition of some compatibility layers (Classic Mac OS, Java, .etc.) to make up for the lack of applications. At this stage, there would have to be really really major benefits to a rewrite to justify the direct cost, not to mention the opportunity cost.

Re:c++?

[Greyfox]

Yes. Dynamic binding and loading is ugly and clunky.Errors you don't catch at compile time are errors that you have to write tests for. You know who writes tests? No one, that's who! So in practice, errors you don't catch at compile time are errors your users are going to catch. And then you have to debug through an ugly clunky maze of dynamic binding and loading.

But don't get me wrong. I can be... objective... Ok, look. Back in the day we stood at a crossroads. Do we make our changes to C to make it OO fairly lightweight and mostly retain the C syntax, or do we radically change the entire feel of the language. Objective C went for the lightweight approach. Object instances are essentially just pointers to dynamically allocated memory syntactic sugar for pointers to functions around methods. Very C-like idiom and honestly a pretty elegant method of handling things. If you just want C with objective C is worth looking at. It's one step past maintaining some structs with pointers to functions and maintaining OO and inheritance manually, and that's not necessarily a bad thing.

C++ took longer to get where it was going, but it essentially set out for the strictness of ADA in a C like language. It's much more touchy about types and is geared toward catching as much as it can at compile time. Before they got the STL and the C++11 changes rolled in, it was really kind of a pain in the ass to use. It's big and clunky, has a lot of rules to memorize and its error messages are hideous. But in the right hands, with the right libraries, it can be incredibly concise, remarkably fast and a ridiculously powerful tool. In my opinion, one worth learning.

In either case, the first thing you should learn is a unit testing framework for that language. No matter what kind of coding you're doing, there's simply not a good excuse to avoid unit testing any code you're planning to deploy anymore.

And yeah if you go the C++ route, QT is some mighty tasty kool-aid. Sure you have to run their pre-precompiler on your code and will find it much harder if you want to just hook some random non-QT object you have into your system. Sure they demand that their includes be in a specific place in your code. But it's delicious kool-aid! Go ahead, give it a try! I was just playing around the other day with a QT window into which I'd stuffed a QImage that I had loaded up with some pixels from a GDAL raster driver, and it was less than 500 lines of code (Source code's on github if anyone's interested.) Gotta say that was pretty impressive, though still a fairly trivial example.