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++?

[Rinikusu]

I'd go with C++ as the toolchain is mature and if you want to do any GUI work there's Qt, etc. Obj-C is more limited on Linux, but I"m sure the Windowmaker guys would love to have some more folks on board.

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.

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++?

[ShanghaiBill]

I'd go with C++

So would I, even for development on Apple. You can mix C++ and Objective-C. So for Mac OS X apps, you can write 95% in C++, and only use Objective-C for the Apple APIs. I try to keep all the Objective-C crap isolated in separate files whenever possible.

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

Re:c++?

[cheesybagel]

Both languages suck. I would pick C++ as it is more future proof and less niche than Objective-C.

I mostly program in Python or C though. Sometimes Java. I hate C++. C++ is the Swiss Army knife of compiled languages. It does a bit of everything but nothing well. You can always find another language that is better at it on every single aspect you look at. Jack of all trades master of none.

That post on Nim a couple of days back on Slashdot was interesting but I haven't tried the language yet.

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++?

[fnj]

What's the mystery?

#include <iostream>
#include <sstream>
#include <string>

int main(int argc, char *argv[])
{
    std::istringstream iss(argv[1]);
    while (iss.good())
    {
        std::string s;
        std::getline(iss, s, ',');
        std::cout << '"' << s << "'\n";
    }
    return 0;
}

Re:c++?

[Anonymous Coward]

Not a mystery to me, but I already know C++. Your code fails to handle a delimiter at the end of the input, but I digress...

Think about this from a beginner's perspective: "All I wanted to do is split a string, and it's six lines of code?"
None of what you wrote should seem natural to anybody except people brain-damaged by learning and using C++.

Contrast with:

  QList<QString> tokens = QString(argv[1]).split(",");

Stuff like this is the reason Boost exists.

Re:c++?

[Anonymous Coward]

how would your code look if you needed the read string to be utf-8 or at least utf16?

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.

Re:c++?

[Pieroxy]

I think you should be modded funny actually. I haven't done any C++ since college (say, 20 years ago) and reading your code makes me happy that I didn't. The mess of it !

As another commenter pointed out, what if the string is made of UTF-8 and not ASCII ? Such trivialities should be handled at a layer way below this.

Re:c++?

[Carewolf]

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.

I think they were contemporary. They were young and immature together. Both born in 1983.

Re:c++?

[michelcolman]

Objective C++ works well for me. You can not only mix and match Objective C and C++ files, you can use a mix of both in the same files. Just give them the ".mm" extension. No problem usig std::cout from [theView dosomethingWith:(int) i]. Of course you do have to understand both languages, so it takes more time to learn. But you can use the strong points of both languages and pick whatever you need. Need to stick a bunch of UIView*s into a std::vector? No problem!

Re:c++?

[TheRaven64]

First, WindowsMaker doesn't use Objective-C, it's written in C. However, GNUstep, which is the open source implementation of the Cocoa frameworks (originally the OpenStep specification, but they're tracking Apple changes) could use more help! Oh, and we support (on *NIX) a superset of the Objective-C language that Apple supports on their products, so I wouldn't say that Obj-C is more limited on Linux.

That said, and I say this as the maintainer of the GNUstep Objective-C implementation, I'd recommend C++, but with the two caveats:

• C++ is not an OO language. It sort-of supports OOP, but writing OO code in C++ is not the natural way of using the language.
• Don't look at any version of the language before C++11. It's just terrible and will damage your brain.

C++11 and C++14 have cleaned up C++ a lot. With shared_ptr and unique_ptr, you can write code with sane memory management. With perfect forwarding, lambdas, and variadic templates, you can write code that has most of the benefits of a late-bound language. I like a lot of Objective-C, but Apple broke the 'simple, orthogonal syntax' when they added declared properties and a few other things. Any successful programming language eventually becomes a mess of compromises and ugly corners. Some, like Python and C++, start that way, but at least C++ has been slowly improving over the last couple of versions.

The one thing where Objective-C is still a clear winner is in writing libraries that want to maintain a stable ABI. This is insanely difficult in C++ because the language doesn't have a clean separation of interface and implementation and relies a lot on inlining and static binding for performance. The down side, of course, is that once you have a library in Objective-C you're limited to consumers who also want to use Objective-C.

Oh, and Qt GUIs suck beyond belief on OS X - not sure what they're like on Windows, but I wouldn't recommend them for a portable UI. Good MVC design and a native UI is the only way to go if you really want a cross-platform GUI app that doesn't suck.

Re:c++?

[dunkelfalke]

I just wish you QT devs would finally fix the Wacom bug on Windows. It was supposedly fixed long ago, but is still present in QT5 applications.

Re:c++?

[Eunuchswear]

> Using the shift operator to indicate stream I/O seems like one of those "obviously bad choice" kind of things.

Operator overloading in general seems like one of those "obviously bad choice" kind of things!

Yup, nonsense like:

int i, j;
real x, y;
compl z;
...
x = i / j;
z = x / y;

Bloody operator overloading.

Re:c++?

[Eunuchswear]

Ok, now modify the code to split on white smiley face characters.

Re:c++?

[countach]

I find it very odd the claim that OO is not the natural way of using C++. I mean, what is the natural way then?

Re:c++?

[Wootery]

Objective-C++: the ultimate bastard-child language.

C++ is already arguably 4 languages: the preprocessor, C++ core, templates, and the constexpr subset. Now to throw Objective-C into the mix...

I admit it's a neat hack though. Very cool that it actually works, and a nice bit of work by the compiler guys.

Re:c++?

[tigersha]

Bullshit. It is a legacy thing, not a intentional incompatibility thing.

Apple basically bought OS/X from Next together with Job back in the previous century and Next was using Objective C back in the late 80's. All the Apple API's start with NS_. That stands for NextStep. Back ini the mists of time when the C++/Obj C choice was made Apple was not even involved (but Steve Jobs was). In those days a choice between C++ and Objective C was not clear cut, both languages were very new and untried. C++ only became important because Microsoft used it for their Windows API's.

Objective C compiles just fine on any platform, and Apple also uses C/C++ for much of their *NIX userland

Honestly, if Apple/Microsoft/Linus were to rewrite the entire operating system stack from scratch today I doubt that C/C++/Objective C would be used. Or at least someone would think about redesigning the languages. Momentum counts for a lot.

Re:c++?

[jcupitt65]

I'm not sure that's really fair to Obj-C. Another way to explain the differences would be to say that Obj-C comes from the Smalltalk family of OO languages and C++ comes from Simula.

Smalltalk-family languages (eg. also Ruby, Swift, etc.) have late binding: you can join up things at runtime. This is great for GUIs, many common patterns become far easier. Simula-family languages are much more rigid. Almost everything is known at compile-time, so it's safer, but the rigidity makes some things harder to implement.

Writing a GUI in plain C++ is very painful, so all toolkits (that I can think of) add a late binding mechanism. Qt, for example, has signals and slots. Seen from this angle, Obj-C is something like Qt, but with the signal/slot mechanism made part of the core language and syntax.

Re:c++?

[herve_masson]

> Yes. Dynamic binding and loading is ugly and clunky

Really ? You mean: universally ugly and clunky ?

I've spent 10 years in programming Objective-C. I wrote myself an Objective-C compiler at a time none existed (not really a compiler, a parser that generates C and a runtime lib). In the company I used to work for, it helped a great lot more than it has hurt. It also made possible very sophisticated debugging and testing environments, thanks to the dynamic bindings of Objective-C. I don't find that ugly and clunky, not even in the language syntax details.

My point is that dynamic bindings and introspection are immensely powerful tools. They enable generic programming in a clean way as long as you know what you're doing. You may reach similar results with strict typing language, or code generators (thanks visual c), sure. I don't think it's that easy though.

You may hate it for the reasons you mention (Prone to errors because too much things pass the compiler task), which are perfectly valid. But writing it's inherently "ugly and clunky" seems really missing the point here. "Dangerous" is a better word maybe ?

In the other hand, I've seen many C++ programmers lost in their code that no one but the compiler could barely understand a few month after writing. I'm absolutely not saying c++ is inherently bad and/or difficult; it's just about the people who use it and the rules your team adopt to make it coherent and intelligible.

Re:c++?

[TheRaven64]

C++ is a language that is very good for generic programming. It doesn't really meet Alan Kay's definition of OO (and he's the one who coined the term), nor does it pass the Ingalls Test for OO. It has classes, but method dispatch is tied to the class hierarchy so if you want to really adopt an OO style you need to use multiple inheritance and pure abstract base classes, which is a very cumbersome way of using C++.

The worst C++ code is written by people who are thinking in C when they write C++, but the second-wrost C++ code is written by people who are really thinking in Smalltalk. If you're one of these people, then learn Objective-C: the language is far better at representing how you think about programs.

Any programming language can be used to write code in any style. You can write good OO code with a macro assembler if you want. However, every language has a set of styles that fit naturally with the language and ones that don't. You can force C++ to behave in an OO way, and it sort-of works, but it's not using the language in the most efficient way.

Re:c++?

[NJRoadfan]

Could Objective-C evolves, now that the pope is no more ?

Nope, it was swiftly replaced after his demise.

Re:c++?

[NJRoadfan]

Microsoft used plain old C for Win32. That cruft known as MFC used C++.

Re:c++?

[gbjbaanb]

C++ is a language that is very good for generic programming. It doesn't really meet Alan Kay's definition of OO

To be fair, there aren't very many that do!

Re:c++?

[TheRaven64]

There are a few. Smalltalk obviously does, as does Self. Lisp also can, depending on how it's used. JavaScript is probably the mainstream language that fits closest (it's actually very close to Smalltalk). Java and C# both mostly do, though they wouldn't count as pure OO.

Re:c++?

[BasilBrush]

Division is a single concept, whether it's ints or it's reals and complex numbers.
Bit shifting and stream i/o are completely different concepts.

Re:c++?

[michelcolman]

C++ is already arguably 4 languages: the preprocessor, C++ core, templates, and the constexpr subset. Now to throw Objective-C into the mix...

You just summed up all the things I like about it ;-)

Re:c++?

[BasilBrush]

In Obj-C:
NSArray *items = [string componentsSeperatedByString:@","];

Re:c++?

[BasilBrush]

I try to keep all the Objective-C crap isolated in separate files whenever possible.

As we established in previous stories, you don't code in Objective-C at all. You claim experience you don't have.

Re:c++?

[JoeMerchant]

It's not FUD it's NAE - Not Applicable Elsewhere.

Objective C is mandatory in the Apple software realm, obscure elsewhere.

Re:c++?

[Greyfox]

boost::signal2 and boost::bind add signals and slots, too, and they seem more intuitive to use than QT's version. They've also been accepted into the language standard in C++11, though I'm still using the boost versions of a lot of the C++11 stuff for compatibility with older compilers. They make a great addition to library code -- I use signals in data factories to signal the availability of new objects. They're also pretty bulletproof in terms of type safety. The compiler will detect that you're trying to attach a incompatible function at compile time and you can adjust the parameters as you need to with bind. Just don't forget to pass the "this" pointer to objects!

Re: c++?

[iluvcapra]

Exactly, they're a single concept, so they should use the same operator. And if C++ don't have overloading, that would be impossible.

"Concepts" don't come from a language, they come from the programmer.

Re:c++?

[Maury Markowitz]

> Objective-C is an ugly, clunky language

It is now. It certainly wasn't when I first encountered it in 2000, running on OpenStep. Back then it was clear, far cleaner than C++, and the libraries were (and are) fantastic. Say what you will about Qt, all of it's true, but everything from strings to db programming was joke on OpenStep compared to anything else out there. Which is why the company existed at all at that point, the financial guys used it a lot.

But fast-forward a decade to 2010 when I next looked at it for an iPhone program. Uggg! What an abysmal mess! I can't believe it's even the same language! So many one-off @ commands and bizarre "well, you need to know that..." In spite of all the problems in beta testing a *languages*, I still moved to Swift ASAP. Swift is currently about what ObjC was when I first saw it - relatively lightweight and fairly clean. I'm sure that will change, but for now...

That said, C++ remains a mystery to me. The syntax steadfastly refuses to lodge in my brain. I had the same problem with Lisp, which is saying a lot. But as others have noted, it remains the only real cross-platform system one can use for base logic and then plug into the underlying GUI language whether that be ObjC or Java. The only thing that comes close is C, and I still debate which language is better to use in these cases.

Re:c++?

[jellomizer]

I tend to agree, C++ gets its popularity just because you can code normal C in in it, but it does very little to put you in an OO mindset, you can use OO principles if you choose to do so, but thats it.
The issue that I have with C++ is the syntax get cluttered with symbols. ->, *, :: , >>, etc... When you are proficient at the language, they make sense, however while learning it, or having to relearn, after a period of inactivity, it isn't like riding a bike... You do forget, and have to relearn it again.

Re:c++?

[Maury Markowitz]

> Dynamic binding and loading is ugly and clunky

I really can't agree with that. Quite the opposite, given that dynamic binding solves a very very common problem, and that the code required to do the same in a non-dynamic language is *extensive*, I have always found that compile-time bound languages are far more clunky and ugly. I thought that was a pretty common opinion among people that have used both.

>.Errors you don't catch at compile time are errors that you have to write tests for. Y

Sure, that's true, but of the total set of errors that compliers don't catch, the ones that are caused by dynamic binding is a tiny subset. I still get dangling objects and nulls all the time in my C# code, probably 50 to 100 times as often as I've had a binding problem in ObjC. It is a problem, sure, but it's not *the* problem.

Quite the opposite, in fact. I would posit that nulls remain the largest problem in modern code. ObjC (and Swift) allow you to call methods on null. That means you get a null instead of a crash, which in most cases is what you want in the first place. Yet in my C# and VB.net code, I have to liberally sprinkle all sorts of checks and such. C# is better in this regard than VB, and VB is adding support for better handling in the next release because it's so bad at it, but neither comes remotely close to the way ObjC handled it, from the start.

So, while dynamic binding may indeed result in some uncaught runtime exceptions, I'd say ObjC programs *on a whole* have far less runtime exceptions due to other design decisions.

> In either case, the first thing you should learn is a unit testing framework for that language

Well you've just invalidated your own point, haven't you? If the problem is runtime errors, and the solution is unit testing, then the relative paucity of dynamic binding problems is going to add maybe zero lines of code to your test suite.

Re:c++?

[VGPowerlord]

You're confusing widening conversions with operator overloading.

Re:c++?

[Maury Markowitz]

> it was swiftly replaced after his demise

Nice.

Re:c++?

[Maury Markowitz]

> JavaScript is probably the mainstream language that fits closest (it's actually very close to Smalltalk).

It's much closer to Self. IIRC it was a fork.

Re:c++?

[pla]

Three includes! Two methods! A loop! Six lines! And he didn't call it "George" like you would have!

...vs pulling in a massive amount of overhead with something like Boost or QT, complete with their own huge list of dependencies... For a program that may well do nothing more than parse a CSV file.

"What if" if needs to work on UTF-16? No, wrong question by a wide margin - What if it doesn't? Do you always use a CNC to cut a 2x4 in half, just because you have access to one? What if you have 5/4 lumber? What if you have cellular PVC? What if you have rebar? All valid questions - And all completely irrelevant if you just need to cut a 2x4 in half.

We can all agree that building some not-strictly-required flexibility into our code generally counts as a good thing, that will frequently save us time and effort down the road. We don't need to build a tilt-a-whirl for someone that wants a tire-swing, though.

Re:c++?

[TheRaven64]

Not really. Self has multiple prototype chains, Smalltalk and Java have only single inheritance. Both JavaScript and Smalltalk lack any declarative mechanism for defining classes in the language and do so by manipulating objects.

Re:c++?

[Eunuchswear]

No I'm not.

i / j is operator/ (int, int)
x / y is operator/ (real, real)

That is the very definition of overloading.

Re:c++?

[david_thornley]

Near-compatibility with C is one big reason why C++ became popular, but I suspect it's not a big thing any more. There's a growing movement to teach C++ as its own language, sometimes referred to as modern C++. (Unfortunately, some people still start at C and then add features until (a) the course is over, and (b) they're not really near modern C++ yet.)

As far as the symbols you complained about, only :: is C++-specific, the others (along with every symbol on my keyboard except for `, @, and $) are from C. I haven't had problems with getting away from C and C++ for a time and forgetting these, but I steadfastly refuse to learn the operator precedence table.

Re:c++?

[david_thornley]

C++ uses encapsulation heavily, and RAII would be impossible without it. Inheritance is discouraged when unnecessary, since it's a very tightly coupled relationship. Unlike some languages that have almost everything as objects in one inheritance tree, C++ inheritance trees are normally shallow, and a lot of class definitions will have neither superclasses nor subclasses.

C++ uses templates to do generic programming, and this is probably the most distinctive feature nowadays. The template language is screwy, but there's a lot of extremely powerful templates available in the Standard, including the container, iterator, and algorithm libraries that descend from the original STL. It isn't necessary to know how to write a template in order to benefit greatly from them.

Re:c++?

[TopherC]

But don't forget the context. It isn't "I want to write a program that splits a string on commas," but "I want to write a program that will grow in complexity." Like most programmers, I read a whole lot more code than I write. I like to read code that is expressive enough that the little things (like string splitting) are simple statements while the over-arching objectives and design issues are stated in comments. Also anything that's subtle should be commented, but not "// This splits a string. Check my work please!" Or "// Opening a TCP socket," etc.

C++ allows you to write very clever code, which is admittedly fun to do. But it's wearisome to read that stuff because you have to both figure out what it's doing and also prove to yourself that it's correct and handles malformed data properly. Unless you're optimizing some crucial piece of code (which C++ is potentially good for), it's much better to write expressive code.

I haven't done too much with QT, but I think it is well structured and helps you to learn to write good C++. Some will say that's an oxymoron. But I've seen what can only be judged bad C++, and know that QT could have been a whole lot worse than it is.

Library dependencies -- that's another subject. You're going to have them one way or another. Picking your libraries well is a matter of taste and what you're long-term plans are.

Re:c++?

[Vyse of Arcadia]

Any programming language can be used to write code in any style.

I would love to see object-oriented Brainfuck.

Re:c++?

[PhilHibbs]

To be honest, using a method called "getline" in order to break up a string on commas is hardly intuitive.

Re:c++?

[tibit]

Frankly said, I'm at this point just tired of people who can't set up their build tools to automate common tasks, and who think that code generation is some disease that has to be valiantly fought, because obviously if you call anything besides the compiler it's too complificated.

Look, you're wasting lots of your time by not using code generators. And I do mean lots and lots. You even publicly and proudly admit to it. In any project of considerable size, you'll be using dozens of tools to produce the final executable, the documentation, etc., so you just make yourself look very silly.

If you're whipping up something quick and dirty in Qt, you don't care about any code generators that Qt internally requires. A four liner .pro file does the job, and Qt Creator sets everything up for you anyway. For more complex projects it's your pick between qmake+make and cmake, but both are fully supported.

Your rant sounds silly.

Re:c++?

[brambus]

Dynamic binding and loading is ugly and clunky.

So dynamic binding and loading is ugly and clunky. Remember this boys and girls...

It's much more touchy about types and is geared toward catching as much as it can at compile time.

And the reason for that is because it's statically bound (well, for the most part, apart from "virtual" methods). It has dick-all to do with "correctness" or whatever. It's simply because even if a subclass has its own implementation of a parent's method, it'll still call the parent method - this goes against one of the core principles of OO: polymorphism. This means that even *if* you wanted to override a method from a parent class in your subclass, unless the parent has it marked as virtual, you're SOL. In Objective-C, meanwhile, it'll work exactly as you'd expect - the child method will get called. Also don't assume that simply because Objective-C is dynamically bound that it doesn't watch your fingers. If you aren't a stupid programmer and have warnings turned on, it'll warn you of weird stuff, such as sending a message to an object of a class which is not known to have it declared. I've written a fair amount of Objective-C code and only encountered sending an incorrect message to an object a few times. Now allocation-related stuff, that's the killer! But it's the same in both languages (in fact, one could argue that ObjC is a bit better, as it at least gives you a ref-count garbage collector, whereas in C++ you're on your own).

[C++ is] big and clunky, has a lot of rules to memorize and its error messages are hideous.

And so now C++ is the clunky one? TBH, it really comes down to personal preference. I like dynamically bound languages, because it fits my style of thinking. If you're writing complex interactions between objects, it cuts down on the amount of code needed to write quite a bit and if you follow the suggestions of the compiler, you're very unlikely to shoot yourself in the foot. OTOH, I understand that if you're after 100% valid programs where static analysis gives you a lot of confidence ahead of time, then C++ is probably the way to go (although I'd prefer C in that case). It's really about style and personal preference. Neither is more or less clunky, it depends on what you want to do with and how you want to do it.

Re:c++?

[pla]

You make it sound like having a non-stupid, modern string class is a monstrosity that needs 16 cores to run.

You can split a string in any language. If you want to write in C++, write in C++. If you want to write in VB.Net, write in VB.Net.

C++ doesn't need to look like VB.Net just because you don't like the syntax.

Re:c++?

[ChrisMaple]

If you like C, you can use just a few features of C++ when it's to your advantage. For instance, let's say you had to do a lot of math on 24 bit integers. In C, you'd have to do
c = add24(a,b);
In C++, you could write a 24 bit integer class, override the + operator, and get a much more readable
c = a + b;

Infrequent use of C++ features sometimes helps a great deal.

Re:c++?

[angel'o'sphere]

Care to explain why C++ does not fulfill "Alan Kay's definition of OO"?
It has classes, but method dispatch is tied to the class hierarchy ... I doubt Alan Kay made any statement about that. ... so if you want to really adopt an OO style you need to use multiple inheritance and pure abstract base classes,
This is complete nonsense as it has no influence on method dispatch.

Re:c++?

[cheesybagel]

The 'much more readable C++' also hides the fact that you might be doing an expensive function call in that '+' operation. It obfuscates code. Java also does not have operator overloading and I never felt that it hindered me in any way. In the past I did write a lot of thick OO C++ code but now I always avoid it like the plague. The closest to C the code is the more readable (as in understandable) and maintainable it is.

Re:c++?

[Dutch Gun]

It has dick-all to do with "correctness" or whatever. It's simply because even if a subclass has its own implementation of a parent's method, it'll still call the parent method - this goes against one of the core principles of OO: polymorphism. This means that even *if* you wanted to override a method from a parent class in your subclass, unless the parent has it marked as virtual, you're SOL.

If you read about Stroustrup's design intentions, he absolutely believed that strong type safety was an important part of making programs safer and less bug-prone. Obviously, the creators of Objective-C (and many other languages) chose to follow a different design philosophy. It's probably not helpful to get into a debate about which one is "correct", as that's obviously going to be pretty subjective.

As far as the example you give, this is because C++ always adheres to the "zero-cost principle", meaning that the language designers don't believe C++ developers should pay for features they're not using. Virtual functions are more expensive to call than non-virtual, and you can't always determine at compile time whether one will be called or not, so it's left to the programmer to tag the function. It has nothing to do with "going against the core principles of OO". It just means C++ will happily let you shoot your own foot by ignoring the language rules it requires the programmer to adhere to.

This is why people consider it one of the more difficult languages to master. It's a powerful tool, but has many sharp edges. For programmers like me who value C++ primarily for it's runtime efficiency, this is absolutely the correct design decision. There are plenty of better languages to use if your primary goal is programmer efficiency.

BTW, you're a bit out of date regarding C++ and allocation. Modern C++ now has several built-in smart pointers (including ref-counted versions) which makes modern C++ feel a lot closer to C# with it's garbage collection than to C-style manual memory management.

Re:c++?

[brambus]

As far as the example you give, this is because C++ always adheres to the "zero-cost principle"

Also describable as the "zero-flexibility principle". In Objective-C extending existing code is super trivial. In C++, unless the author of your library *expected* what you're about to do, you're pretty much SOL. For example implementing a native RPC mechanism in Objective-C is about as complicated as implementing -forwardInvocation: and ferrying the serialized NSInvocation object between sockets. In C++, it just can't be done (well, unless you're willing to write some sort of custom VM!). Also, in practice, the overhead of Objective-C's dynamism is pretty much negligible (speaking from experience having written some pretty heavily real-time code for video streaming in Objective-C that's running the server-facing portion of a few dozen thousand STBs in the field right now). 90% of the time you're running 10% of your code. Write that portion in highly optimized pure C and the rest in objects and you'll get the best of both worlds.

For programmers like me who value C++ primarily for it's runtime efficiency, this is absolutely the correct design decision.

TBH, I've never seen the logic of this statement. Given that most code written in pretty much any app is just high-level scaffolding around a few really core high-perf algorithms, why try and shoehorn the same language into these two completely different usage scenarios. That's IMO asinine and C++'s extreme levels of complexity and sheer volume of features is a testament to that fact.

BTW, you're a bit out of date regarding C++ and allocation. Modern C++ now has several built-in smart pointers (including ref-counted versions) which makes modern C++ feel a lot closer to C# with it's garbage collection than to C-style manual memory management.

I stopped paying attention to C++ by the time the spec document collapsed under its own gravity to form a black hole.

Re:c++?

[cthulhu11]

NeXT actually poached the lead Objective-C developer in the 1988-1989 timeframe. Is C++ these days legitimately OO? Back then it wasn't. Objective-C on the other hand has the Brad Cox stigma.

Re:c++?

[lsatenstein]

I'd go with C++ as the toolchain is mature and if you want to do any GUI work there's Qt, etc. Obj-C is more limited on Linux, but I"m sure the Windowmaker guys would love to have some more folks on board.

I concur, C++ is the way to go. Once you know C++ you will quickly adapt to other OO languages. (I started with Python3)

Re:c++?

[vilanye]

Mandatory?

I guess you never heard of Swift?

Re:c++?

[JoeMerchant]

You can program your Mac with Scratch, if that's what you are into.

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

[antifoidulus]

Which is actually kind of sad, as an object oriented superset of C Objective-C is much much better than C++(for starters it's an actual superset of C, unlike C++). However it never gained any traction outside of the Apple ecosystem.

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.

Re:C++ is the only logically option

[Pseudonym]

I knew that would get voted down. Let's just say I'm in good company.

Re:C++ is the only logically option

[Anonymous Coward]

Given structs and function pointers, one can accomplish anything that would be accomplished with classes, interfaces, and inheritance. So, it is true that one does not need these things.

The purpose of objects, interfaces, and inheritance is not to do something that couldn't be done before, but rather, to provide useful code organization and visualization so as to minimize developer time and effort. Anyone can get this wrong, of course, but that isn't the fault of the system itself. But where it cannot be gotten right, a simpler approach should be used instead.

Re:C++ is the only logically option

[Pseudonym]

The purpose of objects, interfaces, and inheritance is not to do something that couldn't be done before, but rather, to provide useful code organization and visualization so as to minimize developer time and effort.

That's the theory, anyway.

Believe me, I'm a fan of advanced type systems. Interfaces, and IS-A subtyping are useful and important. However, implementation inheritance (as Simula and its descendants understand it) is a broken concept. This is one of the reasons why even OO people alway say to prefer composition over inheritance.

Re:C++ is the only logically option

[tgv]

Sorry, but STL is not a good example of C++'s superiority. It's bloated and unreadable due to C++'s template syntax. I still prefer my homegrown lib for lists and trees and such, but when I have to choose some publicly available software, I pick Boost over STL.

For the rest: Objective-C is not a great language. It has some cute features, but they are primarily useful for GUI programming and don't really contribute to better software development.

Re:C++ is the only logically option

[countach]

Errm, what does Objective-C have OTHER than an object system? That's all there is in the Objective part of Objective-C.

Re:C++ is the only logically option

[countach]

That's a little bit prejudiced. There's absolutely nothing wrong with using Objective-C for general purpose programming. Whether it has enough to offer to make it one's first choice is another thing, but its perfectly serviceable, and in so far as being object oriented, is a decent platform for object development.

Re:C++ is the only logically option

[countach]

As someone who did some programming in Sather, which explicitly split up interface and implementation inheritance, I don't know how you justify the claim that implementation inheritance is "a broken concept".

Re:C++ is the only logically option

[tgv]

Prejudiced, why? I did do my share of Objective-C programming (some 50k lines by the last count), but it has little to offer over C for tasks other than GUI programming. I think that e.g. C# is a better general purpose language.

Re:C++ is the only logically option

[Maury Markowitz]

> but it has little to offer over C for tasks other than GUI programming

That strikes me as similar to saying a Porsche has little to offer other than performance and fun. That statement is demonstrably true, but appears to be missing the point. Is it the case that only some programming is GUI-based? Yes. Is it true that almost every program ends up with a GUI? Also yes. Lets not ignore the forest for the trees.

But more directly, I disagree with the statement at its core. ObjC, and other languages like it, offers several features that make *very* common tasks *dramatically* simpler:

1) Late-bound methods. In ObjC you can send any message to any object at any time. That includes dangling pointers or null. What that means is that if you do this...

String x = LoadStringFromFile("a file that doesn't exist")
x.printToDebug

the code runs fine. The answer to any method passed to null is null, which is precisely what you actually want. Why is this useful? Because it eliminates the 10% of the code you write, the code that checks every step of a method like this for any nulls...

someObjectWithFields.aMethodThatReturnsAField.whichIsAnotherObjectWithAField.trim.printToDebug

The correct answer for this method is null in the case that anything in it is null. ObjC does that (from now on, I'm using "ObjC" to refer to other languages with similar features, the Smalltalk family). Sure, you *can* put in all the IFs if you feel that you really need to know if Another is null and not AField, but in 99% of the cases I've seen, that's not what you actually need.

This eliminates many, many lines of code from your project, which makes the resulting code smaller and far easier to read.

2) Data models. In conventional languages you can't load an object in a generic class and then have it assume the qualities of your model. Let me give you a recent example from my own code. I have a library that can read and write XLSX files, turning them into Rows, Columns and Items (item is the actual value). My program has Accounts, Contracts and Addresses, which are collections of code. In order to turn the Rows into, say, and Account, I have to roll over the rows and create parallel objects that point back to the Row. It's a complete mess. In comparison, in ObjC (from now on, that's a generic term) I can swizzle the object after it is loaded and that Row magically turns into an Account.

If you don't understand the power of this concept I think you need to look at some actual examples of DB programming under Apple's late, lamented EOF. It is, bar none, the simplest and cleanest object modelling platform I've seen. I understand examples of similar simplicity and cleanliness exist on other dynamic platforms, but I've tried them all on Java, C++ and .net, and I can say from experience that nothing comes *remotely* close. And I say this as someone that's written hundreds of thousands of lines of DB code.

3) Zombies. This is really just a subset of swizzling applied to a real-world problem. You can flick a switch so that when ObjC releases an object it doesn't, it instead swizzles it into a Zombie. Recall (1)... this means that instead of your program crashing, it calls that method on the Zombie. Zombies have one method that gets all calls, and it prints out useful debugging information.

Yes, you can do this in other languages, and some even do it. But again, as in (2), ObjC's *implementation* of this is trivially simple and easy to use.

4) Method signatures are strings. I think this is what you're touching on when you say "good for GUI" but you don't specify. The advantage here is that I can save method calls in files. This has all sorts of interesting side effects. One simple one is that I can bind a button to a method directly... unlike (say) .net, where the button calls a generic method that calls code the development environment writes to call your method. And lets be honest, VS isn't exactly perfect, even when you can read it.

But t

Re:C++ is the only logically option

[serviscope_minor]

I still prefer my homegrown lib for lists and trees and such

Uh so how is your library less "bloated" and more readable than the STL?

ut when I have to choose some publicly available software, I pick Boost over STL

So how on earth do you square that with boost mostly being a proving ground for the standard library?

Re:C++ is the only logically option

[Pseudonym]

Yeah, I didn't word that well. What I meant is, C++ is better than Objective-C because it isn't an OO superset of C.

Re:C++ is the only logically option

[Pseudonym]

It's bloated and unreadable due to C++'s template syntax.

I'm with you on the syntax issue. The greatest weakness of C++ is also its greatest strength: it retains something very close to backwards-compatibility with C. That inevitably means that all the good syntax is taken.

However, "bloated" is a puzzling claim. The whole point of the STL is that you can do things like type "sort" and it chooses the best sort algorithm for the data structure (e.g. merge sort for lists, quick/heap sort for vectors) automatically at compile time. Or you can create an array of 1000 elements, and it will initialise it with object construction or memset depending on the type, and this is all handled for you automatically at compile-time. You do not pay a cost to do this at run-time.

Your homegrown lib can't do that.

[...] but when I have to choose some publicly available software, I pick Boost over STL.

Boost and the STL don't compete. In fact, most of Boost (e.g. Algorithm, Array, Circular Buffer, Container and of course Iterator, among many others) are designed with STL in mind.

For the rest: Objective-C is not a great language. It has some cute features, but they are primarily useful for GUI programming and don't really contribute to better software development.

I've said some slightly uncomplimentary things about Objective-C in this thread, but I do have to admit that it's one of the best compromises between "dynamic"/scripty languages and "static"/low-level languages that has yet been developed.

It's just a shame that it's also based on Simula's broken object model.

Re:C++ is the only logically option

[Pseudonym]

Sather (and Eiffel and Smalltalk etc) are less broken than Simula, I'll grant you that.

I do come at this from the point of view both as an engineer working in the high-performance computing area, and as a programming language theorist. People like Stepanov, Knuth, Dijkstra, Luca Cardelli, Alan Kay, Benjamin Pierce, and many others have written and spoken (sometimes at length) on the problems with implementation inheritance. And the fact that most OO proponents consistently tell you to avoid it ("prefer composition over inheritance") is telling.

However, I would say that the claim of "broken concept" is based not on one single argument, but on independent converging lines of evidence.

Here's another one, which again is not convincing by itself, but adds to the picture: the Curry-Howard isomorphism. One of the signs that you know you've found something interesting is that it turns out to be formally equivalent to something else that's interesting. (Think of the isomorphism between regular languages and DFAs, for example.)

Programming language theorists have found many such isomorphisms over the last few decades, and what's interesting is that programming language features seem to be equivalent to interesting objects in logic and category theory. For example, Scheme-style continuations are actually Pierce's Law in logic. Call-by-value and call-by-name turn out to be dual in the programming language which is isomorphic to Gentzen's classical sequent calculus.

Subtype relationships are pretty well-understood, and interface inheritance has a straightforward interpretation (e.g. see Haskell's typeclasses). However, despite searching for decades, nobody has found any such connections with implementation inheritance.

The industry desperately needs the style of OO that everyone uses to be on a sound theoretical footing, because it makes program analysis and compilers better. Lots of smart people have tried. The fact that we haven't found it by now strongly suggests that it's not theoretically sound.

Re: Classic?

[Anonymous Coward]

Yeah! Learn something new and make new mistakes!

20 years ?

[Anonymous Coward]

If you take 20 years to pick up a new programming language, maybe programming isn't for you.

Java

[buchner.johannes]

I don't expect any contrary opinions here on /.

Re:Java

[BarbaraHudson]

Actually not bad advice, if the poster wants to get into OOP.

Objective-C is the obvious choice if you also want to make money developing for Mac OS X

With Apple switching to swift, you'll be learning an orphan language. Best bet is to learn c, then c++. This way you get the basics first.

However, if you think you're going to make money developing for OSX starting from zero, seriously, what universe do you think you're in?

Re:Java

[bobbied]

I don't expect any contrary opinions here on /.

(Oh you ARE sarcastic....)

Java is not the Swiss Army knife of programming languages... There are things it just isn't well suited for... But generally, not a bad choice for most run of the mill projects where performance and foot print don't really matter. However, if you are on limited hardware or have tight response time constraints, Java is not for you (but you hardware and embedded guys know this already.)

Re:Java

[rwa2]

I would put down Java as a good language for learning how to do OOP stuff in the most verbose way possible. But at least it works as documented, and is well-documented. I find myself spending less time fighting the compiler and obscure memory allocation problems, and more time fighting the shear volume of code. That isn't necessarily a bad thing.

Otherwise, I think I'd have more fun doing something in Python, with some modules implemented in C++ to optimize the performance-critical parts.

Re:Java

[Anonymous Coward]

Actually, I don't think you know what a Swiss Army Knife is good for. I've owned half-a-dozen, so let me tell you.

The early knives were a dream. Just a few blades, and typically a set of scissors. One blade had the makings for cleaning and grooming nails.

The current monstrosities are a joke. Handles so wide you really can't use them effectively, but there's a blade / insert for everything.

In this sense, Java fits the bill. There is at least one library for everything, and sometimes ten or twelve. The performance of the JVM is better than any other non-compiled language (and better than a few compiled ones), with the possible exception of C++ (in some senarios) or C. If you really want to get into performance tuning, one of the fastest minimum latency processing frameworks is in Java. Block oriented I/O without the dual copy problem is available. Infiniband communication channels are available via Java APIs (but that hardware is still quite expensive). That said, the slow stuff is available too (and in droves). If you don't know what you're selecting, odds are you will code yourself into a non-performant corner.

As far as limited hardware, Java has had literally a decade in the small spaces with Java ME, and for slower but real time environments, there are real time JVMs.

So, in short, while there are still a few places where it makes absolutely no sense to use Java, and there are a few environments where Java doesn't fit the bill, nearly every one of your provided examples are poorly thought out, and supported with fallacies.

Re:Java

[narcc]

... There are things it just isn't well suited for...

Like writing computer programs?

Re:Java

[BarbaraHudson]

Java has a similar syntax to c/c++. And it provides an easier way to get started without shooting yourself in the foot too often. This way, with less frustration and time wasted on the details, he can learn both in just a bit more time than just c++.

Re:Java

[Greyfox]

No destructors just kills java for me. Yes, I know you have things kind of like destructors that can run at GC time but they're not guaranteed to. That means I have to rely on the programmer to remember to call close before his object goes out of scope, and he's not going to be able to in all cases. That in turn means he's going to be leaking resources. Which seems to be why a lot of the production MQ servers I've seen pretty much HAVE to be rebooted every three days.

Some time ago I was working for a company that was using Jmeter for functional testing. Don't ask me why, but it seemed to be pretty effective for them. At some point they added an SSH sampler into the mix for it. This worked just fine when you were developing the test and running it from the GUI, but when we ran the test from the command line, it would hang when it should have exited. I went digging around in the ssh sampler code and found that he was closing his ssh connection in what passes for a destructor in Java. This was getting called when the GUI exited, but not from the command line. So the ssh connection would remain open and java would sit there not doing anything, so no GC event could ever take place. Essentially a deadlock with exit waiting ssh to close and that waiting on a GC to happen.

I fixed it by moving the ssh close connection to somewhere else, but it was still rather awkward and would prevent the ssh connection from being reused. You'd have to create a brand new one each time you wanted to use one.

Java seems to encourage this sloppy mentality that you don't have to worry about any resources because the language is garbage collected. If you're going to program in it correctly, it requires as much discipline as C++, and at least as much unit testing. I've met very few java programmers who have either.

Re: Java

[Anonymous Coward]

Java is not an answer. The whole JRE means installing an unsafe browser plugin for most people. Oh, and would you like to improve your websperience with ASK.com? Oracle has poisoned it, at least be decent enough to give Java a nice burial.

Re:Java

[pspahn]

...

Java!

Re:Java

[wheelbarrio]

Java 7 introduced the Closeable interface and try-with-resources statement to give the programmer every incentive to Do The Right Thing in cases like these, and every good Java programmer I know uses them (see http://mina.apache.org/sshd-pr... for topical example of an SSH client implementing Closeable). True, anyone can code badly but that's not the language's fault and in this case I would hardly say that sloppy mentality is encouraged. A poster above noted that C++98 != C++14. By the same token, Java 1.8 != Java 1.2

Re:Java

[countach]

You've probably got more chance in OS-X than most anything else. What do you advocate, CICS mainframe?

Re:Java

[countach]

Errm, I probably would say Java IS the Swiss army knife of programming languages. Jack of all trades, but master of none. Java might not give you the best result, but it will probably give you less aggravation getting there than most anything else, simply because it is easy to get working and running everywhere, there are a ton of libraries existing, and the compile and link model is simply easier to work with.

Re:Java

[countach]

Yes, as has been pointed out, Java since V7 now has try with resources to auto-close stuff. It's not like you can be totally oblivious in C++ either, you can easily lose resources too if you're pathologically stupid.

Re:Java

[countach]

I might add that well designed programs don't generally open and close resources in lots of places in the code. They will abstract that out and have it done in only a few places.

Re: Java

[drinkypoo]

Java is not an answer. The whole JRE means installing an unsafe browser plugin for most people.

Can be disabled

Oh, and would you like to improve your websperience with ASK.com?

Are you new? Download the enterprise installer. It doesn't ask you to install ask.com (or any other bundled bullshit) on install or update.

Don't use Java because it's a dead end, and at that end, lies Oracle. Not because it doesn't work, or because of ask.com

Re:Java

[BarbaraHudson]

"And for the love of God, please do NOT use raw pointers."

Raw pointers are great. I have never, and will never, use a so-called "smart pointer." It's easier to just keep track of who owns what. And TR1 sucks. So does template meta programming. Ditto for the "Gang of Four."

Re:Java

[BasilBrush]

With Apple switching to swift, you'll be learning an orphan language. Best bet is to learn c, then c++. This way you get the basics first.

If someone was planning on learning a language as a stepping stone to Swift, c or c++ would be a bad choice, leading to developing bad habits that will cause frustration when moving to Swift. As I understand it they'd be best learning a functional language, after which they'll approach problems in a way which fits very well with Swift's world view.

I can't recommend the particular functional language, as I DID come up the procedural/oo path.

However, if you think you're going to make money developing for OSX starting from zero, seriously, what universe do you think you're in?

As an indie, perhaps. But salaries are good in OSX/iOS programming.

Re:Java

[BarbaraHudson]

What do I advocate? That the poster forget it. The poster has pretty much NO chance. There's already an over-supply of programmers, and not enough demand. If they've been futzing around since the early '90s (that's more than two decades) and haven't yet touched c, c++, or even java, they are already so far behind the curve and so close to 50 that by the time they get up to speed, they'll be unhireable.

Especially since there's a bunch of hungry millennials who can already eat the poster's lunch.

Unfortunately, this is ultimately just another "I want to change my field of expertise - how do I do it?" There is no short-cut, and in this industry 40 is the new 60.

Re:Java

[Greyfox]

That's handy. Maybe all those MQ servers I've had to deal with in the past will finally stop having to be rebooted every 3 days, if anyone ever gets around to updating them. I've been firmly in the C++ world the past couple of years and have kind of stopped looking at Java since Oracle started being such a dick about the language. If I pick up a java contract in the future, I'll have to familiarize myself with the new features.

Re:Java

[BarbaraHudson]

Consider that in the last 30 years, the only two periods when c wasn't #1 was when c++ demoted it to #2 (1995) and java demoted it to #2 (2010).

As for the horrible gui, neither c, c++, nor objective c has a native gui (cocoa is just a library).

Is java dying? At #2, I think not.

Now, I much prefer c to java - java is over-verbose - but there are ways around that as well.

And there's the fact that Minecraft was developed in Java and it was sold for $2.5 billion. There's still big money in using the #2 language.

Re:Java

[BarbaraHudson]

Perhaps you missed the fact that the OP has been "toying around" with the idea "since the early '90s." That's almost 25 years. Gotta be getting close to 50, if not more. Given a couple of years to get up to speed, they'll still be unhireable because there are plenty of people half that age who already more experienced.

Would you hire someone like that - someone who has been sitting on the fence for a quarter-century before even trying to learn it? Back in that period, Turbo C 2.0 was $100. Chicken feed in comparison to pretty much anything else, and certainly well worth it when a decent 286 PC was several thousand dollars.

Free c / c++ compilers have been around since before the turn of the century as well. And you could just by a linux magazine complete with a distro and compiler toolchain in 2000 for $10.00 or so - no need to download anything on the slow connections of those days. There's no excuse for taking so long to decide to act.

Re:Java

[david_thornley]

In fact, it gets difficult to know who owns what with raw pointers, particularly when they point to data structures that are referenced by more than one function at a time. In modern C++, std::shared_ptr signifies shared ownership, and the object won't be deleted until everybody's through with it (and, yes, you can get cyclical structures that leak memory that way). std::unique_ptr signifies sole ownership, and a raw pointer is a non-owning pointer. That way, a glance at the pointer declaration shows ownership.

Doing template metaprogramming sucks, since the template language, while Turing-complete, is a really awkward functional language. Using templates can be great.

I'm not arguing about the Gang of Four, though.

Re:Java

[serviscope_minor]

Well, I've got one from about 16 years ago but I'm pretty sure they still make them.

It has a large knife, a small knife, a corkscrew, a hook, some scissors, a small flathead blade/can opener combo and a larger flathead screwdrive/can opener combo an awl, a toothpick and some tweezers.

The handle is a good width and I've used all of the tools repeatedly. The main disadvantage is th blade is quite soft and so it's now worn down from multiple re-sharpenings.

Re:Java

[BarbaraHudson]

If you're the programmer, you should make the decision of who owns the pointer on the basis of performance and utility. This is one of the basics that you have to learn good habits around, that's all.

It's any variable naming conventions and comments that should relay the semantic information of use, ownership, and what happens when free() is invoked.

Re:Java

[david_thornley]

Okay, you make the decision that this thing owns the pointer, but that thing has a copy of it. We know that this thing and not that thing is responsible for destructing what's at the end of the pointer, but when should it do it? Instead of figuring that out, it's easier just to use std::shared_ptr.

Variable naming conventions can get difficult, particularly since the variable has to be named different things in different contexts, and comments can easily become wrong when they deal with such low-level issues. std::unique_ptr tells you immediately that this is the pointer owner.

Re:Java

[BarbaraHudson]

It's not that hard. When another object is given ownership of the pointer, set a flag in your object to say so, so that you don't try to free it in the destructor.

Ditto if you have only a copy of the pointer - set the flag to say that it is only a copy.

All it takes is one bit. No need for reference counting, worrying about circular references, etc.

Another way is to only allow the object that creates the pointer to own the pointer, and other objects can only modify the data through access methods in the owning object. As long as the objects that own the data are destroyed after all the other objects, there's no chance of trying to access a non-existent pointer.

Re:Java

[david_thornley]

What that reads to me is that you've come up with a more clumsy implementation of std::unique_ptr, in which you have to maintain flags in every object that uses the pointer, set and reset them properly and consistently, and remember to write the conditional delete in every class that might use the pointer. I really, really don't see any advantage in your method over std::unique_ptr.

It doesn't address shared ownership at all, but requires the owning object to destruct after all using objects have been destructed, It seems to me that, if you have some sort of mechanism to make sure all users have destructed before the owning object does, you may as well use std::shared_ptr, and if you don't have such a mechanism you're making your program subject to memory faults if the path of execution changes. or else you're doing most of your dynamic memory locations up front and having them last throughout most of the program.

Re:Java

[BarbaraHudson]

I noticed you didn't say anything about the second method, which I've used before I started doing this: just keeping track of what your code is doing so you don't have dangling pointers. Unfortunately, most people are too lazy to keep track of their allocations and frees and who owns what.

It's not rocket science, and the last way is the best way in c. It also runs faster using less memory. The path(s) of execution should be well known - if they aren't, your code is bad - after all, programs are deterministic. Even threaded or interrupt-driven programs.

Re:Java

[david_thornley]

The paths of execution can be hard to determine. Deterministic does not mean easy to figure out.

It is entirely possible that different reasonable paths of execution will result in a different natural order of freeing objects. In that case, you can try to set things up so you can prove an order of destructing, or you can keep track of who's using the memory to see when it can be deleted, and if you're doing the latter you'll find it easier and more convenient to use std::shared_ptr.

Re:Java

[BarbaraHudson]

Funny how I never had that problem when writing multi-threaded programs in c or c++. Oh, right, I didn't bother with crap like the stl :-).

You can either exercise total control, and guarantee no dangling pointers, or take the easy way out and pray.

Re:Java

[david_thornley]

Personally, I use the STL libraries heavily, and find that they make my life easier, and exercise total control over pointers with unique_ptr and smart_ptr (haven't had occasion to use weak_ptr yet).

And, no, I don't know why you didn't have problems with uncertain order of execution while writing multi-threaded programs. I have enough problems with mostly single-threaded large programs that run a long time and react to user input

Re:Java

[BarbaraHudson]

Guess I was just more careful - and had a tyrant for a boss. The primary server had to start up 400 threads at start, and never terminate a thread to reclaim lost memory (terminating a thread and restarting it would have too much overhead). The secondary server had the same specs, except only 100 threads. Both servers had to communicate with each other and the outside world, as well as loading a list of modules for each one at startup.

Ran it over a 4-day weekend at 1,000 requests/second on a machine with only half a gig of ram, and when I got back to work, not one byte lost (would have been easy to know because I was running linux and bsd w/o swap. Even 1 byte lost per request would have killed it, or at least killed one or more threads, and there was no provision to restart a dead thread, or a hung one ...).

Anything's possible if you don't accept the "received wisdom" that it's "umpossible" to write c/c++ code that doesn't leak memory and you're willing to test, test, test (and try some weird stuff), like a real challenge, and you have a boss who insists that nothing less is acceptable so he gives you the time to "make it so."

Re:Java

[david_thornley]

That's an impressive achievement, yes, but it seems to me it would have been easier to get the same effect with smart pointers. You still have to put some thought into ensuring that circular references don't occur, but I'd suspect it would be easier than what you did.

Re:Java

[BarbaraHudson]

It's not hard to prevent circular references - just restructure your code to avoid them. If you have a circular reference, you're probably doing something wrong, or at least lazy. :-)

The only trick I used was what every kid hears from their parents - if you take something, put it back when you're finished/ It applies to malloc() as much as it applies to your toys when you were a kid.

Which is why people should learn assembler before learning c or c++ - they'll have more respect for memory allocation.

Re:Java

[david_thornley]

The most common assembler target around is the screwy x86/amd64 architecture, and I really don't want to start anybody on that. I've worked to some extent in six different assembly languages, some for long periods of time, and my brain just blanks out when I try to learn how to program my current chips. I miss the days of the TRS-80 Color Computer: that 6809 had the sweetest architecture I've ever seen in an 8-bit CPU. The IBM 360 had an easy one to work with (of course, that was intended to be programmed in Basic Assembly Language, which was hardly basic).

Re:Java

[BarbaraHudson]

I really liked the 6809, but the 68B09E, along with the mmu that let you move 8k blocks of memory, and Microware OS9 and 512k of ram, multi-tasking was awesome for those days. Of course, now, with the flat memory model for x86, things make more sense. 3 floppy drives ... a whole meg of disk storage! Peripherals for speech, home automation, touch pad. Assembler, c, and pascal compilers. Those were exciting times.

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++, C++, C++

[countach]

Hmm, in my experience few people use C++ any more.

Re:C++, C++, C++

[Anubis IV]

It only even exists because of the hipster mentality to "be different" just for the sake of being different with no real other point.

That's quite the revisionist history you have there, though I do agree with much of the rest of what you've said.

In truth, both languages saw their first releases in 1983 (though they had both been under development for a few years prior), both languages were being actively developed in parallel at that same time, and Objective-C was selected as the basis for NeXTSTEP back in the mid-80s, before the meteoric rise of C++ had yet begun in earnest. Given Apple's financial state in the late '90s, their desperate need for a new OS, and their past failure at building a new Mac OS themselves, they were forced into a position where they needed to purchase an OS from someone else. As such, their decision to purchase NeXT and use NeXTSTEP as the basis for what would become both OS X and iOS was born more out of desperation and an acute awareness of their precarious financial situation than out of a hipster mentality to "be different".

That said, I completely agree with your opinion regarding which language is the better one to learn. For all intents and purposes, Objective-C really is just single-vendor language, as you pointed out, and it's slowly being obsolesced by that vendor in favor of a different language, meaning there's an indefinite expiration date on its life. In contrast, C++ continues to be actively developed, and while it may be getting overshadowed a bit in more recent years, it's still strong and will doubtless still be alive and kicking for several decades to come.

C++14 != C++98

[gentryx]

I wish people would stop treating modern C++ as if time had been standing still in the past decades. Yes, C++ is complex, but also expressive. Modern features (e.g. lambdas+auto+templates) often let you write code which is just as concise as its Ruby counterpart, but much more efficient.

Re: C++14 != C++98

[Anonymous Coward]

And almost as hard to read as perl.

Re: C++14 != C++98

[RightwingNutjob]

Only if written by perl programmers. The dynamic type checkers are a godsend for anyone doing lots of ipc between different processes and the user. A little bit of ugly in one place can make the rest pretty.

Re:C++14 != C++98

[sexconker]

I can read and understand C++.
C++ on the other hand is an indecipherable bizarro language that makes only half sense 90% of the time and only 90% sense the other half of the time.

It's worse than Old English vs. English.

Re: C++14 != C++98

[lq_x_pl]

A coworker of mine refers to perl as a 'write-only' language.

Re: C++14 != C++98

[Anonymous Coward]

1996 called and it wants its bad joke back.

Re: C++14 != C++98

[Anonymous Coward]

1876 called, they need you and Mr. Watson.

Re:C++14 != C++98

[Pseudonym]

I wish people would stop adding to C++. C++ as it stood in 1998 was a good, if somewhat complex, language.

That's because in 1998, we didn't know that Simula-style objects were deeply unsound.

It's all the features which have been added since then which have made C++ useful. Unfortunately, the main reason why new features tend to be added to C++ is to fix the previous round of features.

Re:C++14 != C++98

[Anonymous Coward]

>loses all the advantages of a typed language
No it doesn't. You still have strict typing, you just don't need to tell the compiler what the type is as it will infer it from the rhs. If the function I'm calling (say std::unordered_map::begin()) returns a specific, known type, why the hell should I have to type out the type AGAIN? There is no reason.
auto it = propertyMap.begin(); declares a type that can hold the output of that function call and CANNOT EVER hold another type. It's exactly like typing std::unordered_map::const_iterator it = propertyMap.begin(); except far far less noisy.

>Any code review that uses them is an auto bounce and fix.
Wow. You need to actually learn how to write code

>if you're using it for anything other than a container class, odds are 98% that you're writing hard to follow, hard to maintain code that should be rewritten
You are a shitty dev. Templates are amazing for things beyond templates that are not containers. Such as policy based coding. For a simplistic example, look at some of the boost math libraries. By default, it uses long double. But maybe you're on a machine that only has floats so you want to do you bessel function math using a float. So you can toss a `` in the type and it works.

I get the sense that you learned how to use C++ in the late 80s/early 90s and don't actually know how to use it anymore.

Re:C++14 != C++98

[Shados]

What's readable or not is relative to the context of the reader.

A lot of the features that were added, were only added once they were pretty much standard everywhere else.

I remember the first time I saw a lambda in a language... var foo = (x, y) => x * y

What...the...fuck...is going on there.

Of course, now that syntax or slight variations of it are everywhere, so most people will be able to read the above just fine, even if their language is choice doesn't use that exact syntax (ie: ruby). The C++ version is a little messy, but it sure as hell was needed.

Same thing can be said of most of the additions.

Re: C++14 != C++98

[narcc]

1972 called, they're still pissed you returned their 'write-only memory' joke in such poor condition.

Re:C++14 != C++98

[nmb3000]

That's because in 1998, we didn't know that Simula-style objects were deeply unsound.

I'm interested in learning more about this. Would you mind elaborating, or sharing a link to an article discussing it?

Re:C++14 != C++98

[khellendros1984]

Pseudonym posted this earlier in the thread, and I think that some of the ideas in the interview are what they're referring to.

Re:C++14 != C++98

[Pseudonym]

khellendros1984 gave the link to the Stepanov interview, but there's also this and this and this among many others.

OOP is starting to decline now. It's already dropped out of high-performance computing. While Moore's Law hasn't slowed down yet, the clock speed bubble has burst. RAM is larger than it's ever been, but accessing it is more expensive than it's ever been relative to the CPU speed. All those extra transistors are going into more parallelism (SIMD, ILP, more cores, etc) instead of more cycles per second, and OOP is poorly-equipped to exploit this.

Re: C++14 != C++98

[ClickOnThis]

1964 called. They want their APL manual back, along with the "write-only language" jokes.

Re:C++14 != C++98

[Hognoxious]

I can read and understand C++.
C++ on the other hand is an indecipherable bizarro language

And we won't know until we open the box.

Re:C++14 != C++98

[AuMatar]

I'm cool with nullptr for 0. But auto absolutely causes bugs. I've seen it, where programmers assume the auto datatype is one thing and it turns out to be another. It was a major performance issue in a program I debugged. Turns out the compiler assumed they were using floating point where they wanted to use int, and the processor didn't have a floating point unit, so it was all emulated in software. Unfortunately it wasn't found until after release.

In addition, it decouples the data type from the code in maintenance. Want to know what that auto loop is actually doing? You need to find and check wherever the container was defined. This takes time, and leads to bugs when maintainers forget or make the wrong assumption. For saving 10 characters at writing time you cost orders of magnitude that when maintaining the code.

Furthermore- the reason for auto was they fucked up the STL by adding too many features (allocators) and insisting on their algorithms library (which in 15 years of writing C++, I have never seen used) being compatible with pointers as well without using a wrapping class. Stupid, stupid ideas. You don't perpetuate mistakes with new features which add new problems- you correct them.

I completely understand the new features of C++- I just think the vast majority are a bad idea.

Re:C++14 != C++98

[TheRaven64]

The main advantage of auto is in templates, where the type is something complex derived from template instantiations. You simply don't want to make it explicit. Oh, and in lambdas, where explicitly writing the type of the lambda is very hard (though you generally cast to std::function for assignment). As to using a float instead of an int... I have no idea how you'd do that with auto. The type of auto is the type that you initialise it with. If you're using a platform where you don't have hardfloat, then why do you have APIs that return floats? There's your bug, the use of auto was just a symptom.

And if you've never seen anyone use the algorithms library, then you must be using C++ in a very specialised environment. I've not seen any C++11 code that didn't use std::move. I've rarely seen a nontrivial C++ file that didn't use std::min or std::max, and most code will also use std::copy. The only code that I've seen that didn't use the algorithms library included is own, poorly optimised and buggy, versions of several of them.

Re:C++14 != C++98

[countach]

You _can_ write very efficient code, and you _can_ write very concise code, but the mental effort required to make all that happen means that few people think it is worth the effort.

Re: C++14 != C++98

[tylikcat]

+1

(Though, in fact, I've run across perl programmers who write structured, well documented code.

Seriously. And I hadn't been drinking or taking drugs at the time.)

Re: C++14 != C++98

[halivar]

I GOT IT!!! I GOT IT!!!! *look around sheepishly* I... I got it....

Re:C++14 != C++98

[AuMatar]

Float for autos- someone used the wrong version of a library function that returned float to initialize the auto. Kid was new, he didn't know the effects it would have. Auto wasn't the bug, but without auto the bug wouldn't have existed- the problem would have been minimized to a single call and caused a compiler warning that we would have caught and fixed. Auto made the bug worse.

No, I've used C++ in a very normal environment. STL container classes- used all over the place. The algorithms library? More complicated, harder to understand, and much harder to maintain. Very few places use that. And they shouldn't- while min and max aren't too bad, I would always prefer to see an explicit loop with the code embedded in the loop than a function call where I have to hunt down a functor (another thing that should never have come to be) to find out what the fuck is actually being done.

If you want to write Ruby- use Ruby. Keep that shit out of C++.

Re: C++14 != C++98

[rochrist]

....throws a SNOBOL.....

Re:C++14 != C++98

[david_thornley]

Auto doesn't kill programs, stupid programmers kill programs. The numeric conversion rules are well defined, APIs have to be defined to be used, and anybody who expects something to return an integral type and actually gets a floating-point type is doing something seriously wrong. It sounds like you were probably doing embedded programming (as any reasonably modern non-embedded processor does have built-in floating point), and doing it badly.

Do you want to know what "for (auto i = foo.crbegin(); i != foo.crend(); --i)" does? It traverses foo from end to beginning, not altering the contents of foo. Is there a problem with that? Specifying the type of i instead of using auto doesn't guarantee that foo is the right container to be traversing, and if foo is the right container then there's nothing wrong with the statement.

If you haven't used anything in the algorithms library in fifteen years, you're missing the point of much of C++ and your opinion is worthless. You not only don't understand the new features of C++, you don't really understand C++98. The algorithms library is much too useful to be intelligently avoided.

Re:C++14 != C++98

[erapert]

Auto is the most braindead addition in history, it causes bugs, loses all the advantages of a typed language, and only needs to exist because they fucked up the STL by not using proper inheritance.

You. Are. Talking. Out. Your. Ignorant. Ass.

Auto SOLVES every single one of those things you're complaining about.

Shut up. Now.

Re:C++14 != C++98

[AuMatar]

If you want to use auto, go to a dynamically typed language. Strong typing is a feature, it prevents bugs and saves time and effort in maintenance. If you use auto, you're a shitty programmer. Auto solves NO problems except the number of characters you need to type when declaring stl iterators. Its a bad feature used to patch over other poorly designed features. Which basically describes almost all of the additions in the last 10 years to C++.

Re:C++14 != C++98

[david_thornley]

On a scale of 1-10 for strong static typing, Haskell comes out at about 11. A lot of the typing is deduced, not explicitly declared, so there's the equivalent of heavy use of auto. Auto solves the problem of not knowing the type (common in templates, which preserve strong typing a whole lot better than any object-oriented equivalent), or having a type that is not easy to figure out, as well as simplifying iterator declaration and making it harder to get wrong.

Re:C++14 != C++98

[david_thornley]

Simple variable declaration is where I'd advise not using auto. I hate "auto v = [initialization]" where v is of a fairly simple type. Floating-point and integer types have distinct semantics (what does a/b mean?), and I'd like to make that more explicit. auto is more useful for iterators, since one iterator is much like another.

C++ algorithms are useful. You're better off using them than coding things yourself. You're likely not to use some of them enough to remember them, but something like std::find_if is easier to write than a loop, and can be treated as a value rather than calculated before use.

Re:C++14 != C++98

[exomondo]

If you want to use auto, go to a dynamically typed language.

No, you misunderstand what auto is, it has nothing to do with dynamic typing. It's type is deduced at compile-time, in fact you can find out its type with static analysis.

Re:C++14 != C++98

[AuMatar]

The reason they're useful for iterators is that they fucked up iterators. There should have been a base abstract iterator class with child classes for the various types/classes. Then you could have just declared it as an iterator* and not worried. Rather than providing bad patches they should fix the initial problem. Patching on mistakes just leads to problems.

Re:C++14 != C++98

[AuMatar]

-You seem intent on sticking to your view regardless of all the evidence to the contrary
-You call everybody else "shitty programmers" for using auto yet you can't explain what you don't like about it.

Pot. Kettle.

You look stupider every time you post.

Yup that too.

Objective C

[xx_chris]

I hate C++. It's the triumph of syntax over clarity. The only thing it brought to the game was a better commenting method. I can't read a page of C++ without referring to something. I've never seen clear clean C++. I'd never willfully write in C++. Objective C is a measured improvement over C and I vacillate between obj C and GCC. Would that Swift were more like obj C and less like C++.

Re:Objective C

[sg_oneill]

C++ can be clean. The problem is really Macro metaprogramming madness tends to lead to some really strange code and sometimes straight up gibberish. I much prefer Objective C as well, I think its terse, readable and *usually* fairly resistant to a lot of the gunk C++ has accumulated. HOWEVER with that said C++ *can* be well written and clear. Hell even PERL can be. Its just that often it isn't.

Re:Objective C

[Drishmung]

I agree.

I was surprised to find how clean Obj-C was. Eventually, I figured out that it's because of two things:

[1] The weird at first [receiver message] syntax makes it explicit that it is a message passing object model. I find that a natural and helpful model, rather than the procedural-like syntax of C++ and Java. The syntax helps me think in objects, with a clean visual and mental distinction between the Obj bits and the procedural bits.

[2] NextStep is a thing of beauty.

Against that, modern C++ has more modern and advanced syntax (lambda, templates). I'm not sure they make up for it. But rather than C++ I'd go for some other modern language (insert large list here).

Re:Objective C

[Drishmung]

Against that, modern C++ has more modern and advanced syntax (lambda, templates).

Objective C has lambdas.

Sorry, you are right. I'd forgotten about blocks. Objective C 2.0 also added some syntax extensions.

Re:Objective C

[Malc]

Never tried SmallTalk?

Re:Objective C

[chaircrusher]

Using the phrase "Macro metaprogramming" makes it sound like you don't understand C++. There are macros -- as in the C Macro preprocessor, which has been around for 40 years -- and there is Template Metaprogramming, which is a relatively new thing. But they're completely different. If one is serious about re-usable code in C++, one learns how C++ templates work. Templates complement C++ class inheritance by solving a different problem: where class inheritence allows re-use of code to manipulate similar data, Templates allow to reuse code on different data. The simplest example being something like: template Adder { T Add(T a, T b) { return a+b; } }; This template code works on anything -- built-in types or class objects -- that implements the '+' operator. Objective C had one advantage over C++ -- Closures/lambda expressions. Closures are now part of the latest C++ standard, and they're implemented in a more rigorous, type-safe manner.

Re:Objective C

[david_thornley]

In fact, people who don't know $LANGUAGE often can't read a page of $LANGUAGE without referring to something, and even people who do know $LANGUAGE can have trouble with badly written $LANGUAGE. Also, people who don't understand $LANGUAGE pretty well shouldn't write production code in $LANGUAGE. And, of course, most languages should be more like $LANGUAGE.

Smalltalk.

[jcr]

Or to be more precise, Squeak. It's compiled, it doesn't have the cruft of C, and it's as "classic" as it gets.

If you didn't have the "classic" requirement, I'd recommend Swift.

-jcr

Re:Smalltalk.

[Pseudonym]

I was going to say Newspeak, but yeah, Squeak is fine.

Eiffel or Sather would also be good approaches. Don't damage your brain by using languages whose object module is based on Simula.

Re:Smalltalk.

[countach]

Is Sather still alive and kicking? I thought it was dead. Come to that I thought Eiffel was dead.

False choice

[1 a bee]

Objective-C is not classic. That leaves you C++, a rather large language. Large in the sense that there are a lot of rules to learn (with good, practical reasons). But you don't need to know the whole language in order to be productive. And it's fun!

Re:False choice

[Anonymous Coward]

Objective-C actually predates C++

Re:False choice

[Carewolf]

Objective-C actually predates C++

Not really. The are both from 1983, and work on C++ started in 1979 where work on Objective-C started in 1981. I would say they are equally old, and unlikely to have even influenced eachother before birth.

Re: Classic?

[Anonymous Coward]

Yeah! Learn something new and make new mistakes!

No they are not NEW mistakes being made but OLD mistakes in a new way... There is nothing new under the sun..

C++11 or newer

[Anonymous Coward]

C++11 and newer add hugely useful features, and it runs everywhere. Learn it. Use it. Profit.

Go Old School

[radams217]

Have you ever heard of VB6? I'd start there. Nailed it.

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)

Re:Objective-C is a lot of work

[brambus]

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.

Contrast with implementing the C++ base libraries (such as the STL) and you'll quickly see which is simpler. The real difference is that C++ already has more implementations for more platforms. I agree with your conclusion - availability can make its use for your project a non-starter. However, unless we're talking about pretty weird embedded stuff or some weird OS platform like Haiku or something, GNUstep has been already been ported to lots and lots of platforms (including most of the major *nixes and Windows).

Re:Objective-C is a lot of work

[OrangeTide]

I've ported SGI STL to various platforms in the past. And I used to be the system software lead for an embedded product, where I maintained the toolchain and libraries for MIPS and PowerPC (PowerQUICC) products. C++ runtime is a real chore to get right, but it's a path well tread. Obj-C Base Library is technically slightly easier, as the API is smaller, but it's so easy to get wrong and not know it until way later, and there is so little information on getting it right.

A lot of the L4 Kernels use a thin subset of C++ runtime. Which can be a pain to port, and a bigger pain to implement from scratch if you're doing a new clean-room L4.

I really don't like C++ anymore, and I now refuse to accept a jobs where I have to do anything significant with it. I currently have that luxury, but if the job market goes really bad we'll see how well I hold to that position. I'd probably take a job with less pay learning/doing Erlang, Go, Nim, or whatever if C without C++ was no longer a career option.

Re:Objective-C is a lot of work

[brambus]

Wait, so you're porting or implementing it anew? One is not the other. Also, runtime != base library. Did you try to port the base library, or the runtime? Porting or even rewriting the runtime is pretty straightforward and I'm aware of at least one project where a single person did it without much trouble. The base library, yeah, a lot less simple, but still simpler than writing a new stdc++. Also share your sentiment on C++. It's way, way too big for my tastes. For the kinds of work I do (systems stuff, OS stuff, like you), C is plenty expressive enough.

Re:Objective-C is a lot of work

[OrangeTide]

Both porting and implementing, in different situations. L4 being my example of having to construct a small runtime and standard library subset for a kernel environment in C++.

Porting work for was Linux based for CPU variants that were not well supported at the time by most of the standard libraries. the NetBSD based platform at the same job didn't need to run any of the C++ based apps, so I diudn't even bother trying it. I suspect it would have just worked, because after the kernel changes to support the weird MMU were done the user space started up right away.

Re:Objective-C is a lot of work

[brambus]

Ah, ok, cool work. So were you trying to port libobjc and/or gnustep to this platform? gnustep is quite a bit more than a simple basic set of classes. It's perfectly possible (albeit not quite as comfy) to write objc programs which don't use it.

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.

Re:C++ is probably a little bit better

[TheRealMindChild]

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.

You mean using C++ like it is compiled javascript? pffffffffffffffffff

Re:C++ is probably a little bit better

[Required Snark]

C++11 seems to be somewhat useable. However, before that it was a complete disaster. Every time I looked at it, I saw code bases that endlessly re-implemented data structures and storage management solutions.

Even with the standard libraries, there were rarely systems without a lot of custom storage code. By it's own claimed abilities for code reuse, C++ was a failure before C++11.

Every time I brought this up, the C++ fanboys had a fit. I'm rather sure that I was forced out of some jobs because I said this. I know I didn't get hired when I expressed this opinion. I think I was better off not going to those places.

So now I'm going to make the same mistake again. If we take Stroustrup's publication of The C++ Programming Language in 1985 as the start of the ongoing C++ era, then it took over 25 years for the language to become somewhat OK. I can only come to the conclusion that C++ itself was a badly designed language, and this is proven by the time that it has taken to reach it's current state.

In my estimation, C++ was never a good idea. Even though it has improved significantly, it will always be crippled by it's basic design flaws. It is overly complex. It has a vast number of interacting corner conditions that interact in strange ways and can produce bizarre side effects. These have increased over time.

The object model creates problems and you always end up programming around it. Refactoring is invariably difficult; that's where the phrase "brittle objects" comes from. Object encapsulation works poorly. Changing the internal workings of an object is very likely to propagate outside the object. No matter how much precoding design occurs, you will always be modifying objects in ways that required a large amount of code changes in a great number of files. All of this requires a lot of testing.

Debugging has always been a problem. One of the other posts here suggested using CLANG because of it's better error reporting. Thats right now, after 25 years. Let's face it, C++ is legendary for the obscurity of it's compile and link time error reporting. Beyond that, it's not like the run time debugging environment is any better. All that it supports is the kind of break point debugging that was in C. No value added beyond K&R.

So flame away, fanboys. I'm used to it. The truth hurts, and the more squealing I get, the more I know that I am saying the truth.

Re:C++ is probably a little bit better

[ShakaUVM]

>Debugging has always been a problem. One of the other posts here suggested using CLANG because of it's better error reporting. Thats right now, after 25 years. Let's face it, C++ is legendary for the obscurity of it's compile and link time error reporting. Beyond that, it's not like the run time debugging environment is any better. All that it supports is the kind of break point debugging that was in C. No value added beyond K&R.

This is true. I teach introductory computer science using C++, and one of the biggest hurdles for my students is understanding the error messages from the compiler. Half the time they don't mean anything unless you already know what it's supposed to mean.

And that's before even getting to templates. Once you get into templates... /shudder. The error messages are insane.

I tried compiling the rather simple boost program from the "getting started" section here: http://www.boost.org/doc/libs/...

Without the proper library linked in (i.e. just doing a "g++ test.cc"), I get 38 lines of vomit that look like this: .text._ZN5boost11 basic_regexIcNS_12 regex_traitsIcNS_16cpp_regex_ traitsIcEEEEE6assignEPKcS7 _j[_ZN5boost11basic_ regexIcNS_12regex_ traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j]+0x22

Re:C++ is probably a little bit better

[Carewolf]

C++11 seems to be somewhat useable. However, before that it was a complete disaster. Every time I looked at it, I saw code bases that endlessly re-implemented data structures and storage management solutions.
Even with the standard libraries, there were rarely systems without a lot of custom storage code. By it's own claimed abilities for code reuse, C++ was a failure before C++11.

That is how C++ is meant to be used. If you only need fixed standard data structures, you might as well use a higher level language. What something like C++ or C gives you is the ability to write your own data-structures, if you don't need that, they are probably overkill.

C++11 doesn't really change that. It just makes the custom data structures even more powerful, and slightly easier to write.

Re:C++ is probably a little bit better

[countach]

LOL, you just gave me deja-vu about my previous life as a C++ programmer.

Re:C++ is probably a little bit better

[Chalnoth]

Debugging has always been a problem. One of the other posts here suggested using CLANG because of it's better error reporting. Thats right now, after 25 years. Let's face it, C++ is legendary for the obscurity of it's compile and link time error reporting. Beyond that, it's not like the run time debugging environment is any better. All that it supports is the kind of break point debugging that was in C. No value added beyond K&R.

I started development in C++, but have since done quite a bit of development in Java, JavaScript, Go, and Python. I've really come to miss Clang's expressive compile errors, though there are other things about these languages that can be nice. Java is okay. JavaScript is abominable. Go is nearly as good as Java. Python is pretty terrible. As far as compile errors are concerned, anyway.

The other languages have other things that are good and bad, but C++, especially C++11 is great for just getting things to compile. One other cool thing about modern C++ is that it's easier than ever to force more and more errors to occur during compile time, instead of waiting for a runtime error to blow things up in production.

To make the most of C++ really requires good programming practices, though. For that I highly recommend Scott Meyers' "Effective C++" books.

Re:C++ is probably a little bit better

[serviscope_minor]

Well basically no. Given your statement:

  So flame away, fanboys. I'm used to it. The truth hurts, and the more squealing I get, the more I know that I am saying the truth.

I don't expect this reply will get through to you or get meaningful a responses. Others might benefir so here goes:

Even with the standard libraries, there were rarely systems without a lot of custom storage code. By it's own claimed abilities for code reuse, C++ was a failure before C++11.

Well, depending on how you meant that, it's either wrong or a triumph of C++. I have used systems where there has been extensive use of custom containers. The main reason for that was it targeted android and android didn't really ship with C++. It shipped with a language looking much like C++ except with several key features and the standard library nuked. It's hardly C++'s fault for languages that are almost-but-not-quite C++ not being C++.

Other than that one, people mostly seem to make do with the standard containers for things they work for.

In my own code I also make use of two non STL containers, one for images and one for Linear Algebra (vectors and matrices). It's a triumph that these work and look and feel just like native or standard library things. They also don't use custom code: it's either C++ arrays for fixed In my own code I also make use of two non STL containers, one for images and one for
sized objects and backed by std::vector otherwise.

So now I'm going to make the same mistake again. If we take Stroustrup's publication of The C++ Programming Language in 1985 as the start of the ongoing C++ era, then it took over 25 years for the language to become somewhat OK.

No one will deny that C++11 was late. Hell it was meant to be C++0x. However, you're comparing one of the better languages today (C++14) with languages from 30 years ago which is disengenuous. It took C++ 25 years to become a good language relative to others 25 years from its inception. But it was good in the mean time compared to its contempories too.

I wouldn't want to use '98 era C++ now, but I wouldn't want to use Java 1.1, VB6, ancient javascript, bash 2.06 or a host of others now either.

In my estimation, C++ was never a good idea.

Well, the world more or less disagrees with you. It's the only language out there that provides high level abstractions and low runtime penalties. The only serious competitors have come around recently and aren't really production ready. What else scales as well?

Changing the internal workings of an object is very likely to propagate outside the object.

Not if you code worth a damn. Yes we all know objects are sized things and changing the object requires a recompile. However, my code compiles on LLVM, GCC and Visual Studio and ha at various times compiled on MIPS Pro and whatever that sun compiler was. I think someone got it to compile with STLPort on Android too back when that was a thing.

That's 6 complete, from scratch reimlementations of the same objects (the standard library). Yet despite those complete changes no fooling around was required in that regard.

c++

[Anonymous Coward]

I faced the same question recently and decided on C++. Apple, the main promulgator of Objective C, is sort of deprecating it with Swift. On the other hand the direction C++ is taking is appealing; the standards people have adopted some pragmatism in their decisions and listened to real users of the language. I feel like C++ is not actually doomed to collapse under it's own weight.

If you learn the new bits of C++ and use them to write clean code, with memory safely, ownership semantics, return value optimization, type inference and other modern techniques, C++ is a nice language. One bad part is incomplete compiler/linker implementations, but that problem only gets better with time, so your investment ultimately pays off. Another is compile time; #include + huge modern APIs makes for slow builds, but the standards folks know this and are working on it, and precompiled headers mitigate this (to some degree) in the meantime.

Long term, given the two possibilities you've limited yourself to, I think C++ is the better choice.

Re:c++

[Dutch Gun]

I agree. C++ has really seen something of a renaissance in the last few years with C++ 11 and 14. CPU core speed has flattened, and people are realizing that efficiency isn't really something that can be ignored in many cases. Moreover, C++ is and always has been a very portable language, as you can compile it on just about every platform imaginable.

Nowadays, you can write C++ and be assured that you'll rarely have to even think about explicit memory management or leaks. Moreover, what really surprised me was how I actually now prefer the simpler, more versatile, and more predictable referece-counted paradigm over managed memory and garbage collection. The lack of a destructor mechanism means that releasing resources in a predictable manner tends to be a bit less elegant because it's handled in a different way. In C++, memory is just like any other resource.

A lot of people talk about the complexity of C++. There are a couple of things to remember. C++ IS a pretty big and complex language of course, but you don't necessarily have to actually deal with much of that complexity in many circumstances. First, a lot of complexity is related to it's own backwards compatibility both with C and it's own early features. Unless you're maintaining or interfacing with old code, many of those features are largely irrelevant when writing modern C++. If that's not the case, you either have some exceptional circumstances, a very old codebase, or you're not really using the language correctly. Second, C++ can be viewed as two different languages: one suited for library writers, and one for library users (or application programmers). Writing C++ for use in languages can actually be rather difficult - it should be viewed as expert-level language skills. However, C++ actually makes it extremely easy to use a library. And in fact, a well designed library should actually be very difficult to use incorrectly, especially when compared to C.

The language definitely has it's strengths and weaknesses, and I certainly wouldn't recommend it for everything. I'd say C++ starts to really shine when you talk about extremes. If you need your program on a lot of different platforms, need it to run extremely fast, or it has to run with extremely limited constraints, or it's an exceptionally large and complex program, then C++ may be a good fit.

Re:C++

[Bill Dog]

C++ is very complex, and whole swaths of the language can be safely ignored.

And this is why I wouldn't recommmend C++. I loved the language and did it for right around ten years (1999-2009), and saw people online who knew it, but I never met anyone live in my professional career who ever bothered to really learn it. (And now later, I'm having the same experience with JavaScript.)

But I wonder about why the very particular constraint of "classic OOP compiled". I don't think I'd recommend any of those anymore; aside from specialized applications, if what one is going to be writing is large enough to utilize OOP, then VM'ed languages are much more relevant these days.

Re:c++

[Marginal Coward]

Moreover, C++ is and always has been a very portable language, as you can compile it on just about every platform imaginable.

Gosh, I guess you don't remember the early days when Borland, Microsoft, and others had incomplete and differing implementations of the C++ "standard". It was almost impossible to get templates to run on different compilers unchanged. I think it simply took a decade or so for the compiler vendors to fully implement such a complex language. Fortunately, those days are behind us now. Evidently the C++ standard is better specified now, and the compilers are much better at implementing it.

Re:c++

[Dutch Gun]

Well, it definitely wasn't perfect. I cross-compiled code with Microsoft, Borland, gcc, Watcom, and others years ago, but I don't recall it ever being as bad as you seem to remember. If you used a reasonably conservative set of language features, it was definitely possible to keep your code quite portable.

Nowadays, as you mentioned, it's an entirely different situation, as full standards compliance seems to be getting a lot more attention.

Re:c++

[Dutch Gun]

Or you should in theory at least.
In the 8-bit arena (Embedded or old) C++ support is pretty much nonexistent or incomplete.

Heck, once you leave the architectures supported by GCC the portability of C++ becomes questionable.

Was anyone confused that I might be talking about an Apple II or Commodore 64 when I said "just about every platform"? And regarding embedded, it seems relatively easy to find C++ compilers for embedded hardware.

Re:c++

[tylikcat]

"Nowadays, you can write C++ and be assured that you'll rarely have to even think about explicit memory management or leaks."

Crazy talk.

I am not saying this isn't true - I am just remembering that at one point a huge part of my job was auditing other people's server code for, well performance, scalability, reliability and disaster failover recovery. And "Okay, we're going on the magical mystery tour and find all the memory leaks you swore up and down did not exist," was a thing. A really common thing. Ugh.

Seriously, working as a performance analyst for very high traffic highly distributed internet applications... is kind of what brought to biology, really, via non linear dynamics systems theory. As the systems got complex, sometimes their behavior got really weird - and that was so much more interesting than the rest of my job, by that point. (And now, in a rather impoverished ivory tower, I mostly use Python. Heck, half of my rig code is written using PyGame, because I was in a hurry and it got the job done, and it continues to get the job done well enough that I keep modifying rather than replacing it.)

Re:c++

[tshawkins]

Arm, avr and pic all have gnu c++ compiler environments.

Why not Pascal?

[Megol]

Object Pascal that is. It's available in Free Pascal for a lot of operating systems and is a small and fast development environment.

Re:Why not Pascal?

[Em Adespoton]

Because if you go with Object Pascal, you're going to be constantly confusing your stringtypes and endianness. Pascal's a great teaching language (first thing I had formal training in), but since nobody's using it for modern deployment, the only thing you're really going to be able to transition to is Delphi.

Pre-C++11 is a nightmare, as it does so many things wrong OO-wise that I wouldn't really call it object oriented at all. 11+ begins to get more sane, and might be worth learning.

But if you do ObjectiveC, you can significantly add to the percentage of developers who can build for GNUStep :D

Re:Why not Pascal?

[Anonymous Coward]

I've been developing a 3D game engine using Object Pascal for many years as well as contributing to the Freepascal compiler and Lazarus projects. You don't have a clue what you're talking about. confuse my string types? my endiness?

C++ isn't the only language that has evolved. Freepascal is available on all major platforms, it produces code just as fast as any compiled language, we have no problem with getting our string types confused and endiness is a generic programming concern that is no more an issue in Object Pascal than any other language.

The current flavours of the Object Pascal have their roots in Turbo Pascal which then evolved into the Delphi dialect of the language, the latest best being the FPC native dialect which blows C++14 out of the water in many respects.

Turbo Pascal and Delphi were principally designed by Anders Hejlsberg who Microsoft hired to design a little language known as C#. I hear it's quite popular in the business world.

Re:Why not Pascal?

[Megol]

Because if you go with Object Pascal, you're going to be constantly confusing your stringtypes and endianness.

I don't understand what you mean by this?

Pascal's a great teaching language (first thing I had formal training in), but since nobody's using it for modern deployment, the only thing you're really going to be able to transition to is Delphi.

Provably false. It isn't as popular as some languages but it is used for real world products.
Free Pascal is mostly Delphi compatible BTW.

Pre-C++11 is a nightmare, as it does so many things wrong OO-wise that I wouldn't really call it object oriented at all. 11+ begins to get more sane, and might be worth learning.

But if you do ObjectiveC, you can significantly add to the percentage of developers who can build for GNUStep :D

I'm not sure you understand what object orientation refers to in most languages - sure no (?) language that went from a structured to object orientated model are pure OO languages. But most people isn't interested in pure OO languages anyway, most just want abstract data types to be supported.
Some languages that aren't called object oriented but "just" object based essentially "just" support abstract data types. Those that then add inheritance are then called object oriented.

I have done lots of both and say C++ absolutely.

[EmperorOfCanada]

Basically some asshat at NeXT chose Objective-C and that has sort of percolated through Apple. Originally the only way to do iOS apps was Objective-C; so I learned Objective-C. I hated every minute of it. All those damned, [][]][[. The moment I found an environment where I could go back to C++ I was gone.

So if you have to make an iOS app and you must use the iOS SDK then I guess you should learn objective-c. But under any other circumstances learn C++.

Who cares

[Anonymous Coward]

I don't get the whole debate. Programming is independent of language any good programmer should be able to learn a new language in a few days. In my career I've developed applications in four different assembly languages, java, Pascal, C++, basic, etc. It's just a matter of reviewing the syntax and doing the same things in slightly different ways.

Re:Who cares

[Anonymous Coward]

I sure hope you aren't writing your C++ like you're writing your Java. That would make you a terrible C++ programmer.

Re:Who cares

[pspahn]

What is "learning"? Is that running through some prewritten bits to get some calendar application working ... you know, as an abstract concept you then "know". Go through that in two days and then go back to your day job doing whatever it is.

Then fast forward six months. "Oh yeah, I wanna do some more of that coding I learned! I got this sweet idea for an application!"

"... wait, shit ... what was the syntax for that again?"

"... I know the class I need is here somewhere ... "

etc. etc.

You certainly did a great job of "learning" that language in two days, right?

My point is that it is not possible to "learn a programming language" in two (or a few) days. If you use a few programming languages in your day to day job, then yes, you can explore another language and get the general idea in a day or two. But then you go right back to not using it.

You can't learn a programming language unless you use it.

Re:Who cares

[countach]

To some extent it's true you can learn syntax in a few days. HOWEVER, learning to think in a paradigm is a different matter. How long to pick up Scheme syntax? An hour. How long to change your brain to think in Scheme, and not in C/Java/C++/C# ? Well that's a whole different matter.

Re:Who cares

[assertation]

I couldn't disagree more. That might have been true a long time ago, but nobody learns a new language, at least not well, in a few days.

I have seen too many JSPs and Java functions that literally go for pages.

Re:Who cares

[david_thornley]

Programming is not independent of language. The language specifies what sort of constructs are natural and what sort have to be constructed painstakingly. Try writing functional code in C, or generic code in almost any language, if you don't believe me. Different languages emphasize different styles (or "paradigms", if you like that word) of programming, and learning a new one often takes years.

You're also a crap C++ programmer, and probably a crap Java programmer. Good C++ does things in a C++ way, not a Java or Pascal way.

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.

Re:Even Apple is abandoning Objective-C

[maccodemonkey]

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.

They've done no such thing. The biggest writer and maintainer of Obj-C code is Apple. They're sitting on a huge source base they'll continue developing on. Please link me to where Apple has said Swift is replacing Obj-C. Because they haven't. And they've said the opposite many times. Everything I've read/heard is that Obj-C will continue to be a first class language on iOS and Mac (with Swift and Obj-C both being considered first class languages.) You can have more than one language on a single platform. Shocking, I know.

Not to mention, for such a dead end, Apple's still writing a lot of new Obj-C. The iWatch OS (what runs on the watch itself) is Obj-C. Apple has not shipped a single API on Mac or iOS written in Swift. Not one. So it makes zero sense that Apple would consider Obj-C a dead language, and yet continue to write source they'll have to maintain for years in it. And if you think Apple is going to rewrite the millions of lines of Obj-C in Mac OS X and iOS in Swift, you really don't understand software engineering very well.

Another problem is that Swift is missing basic language features. Obj-C can link to C++ code. Swift? Nope. That alone means Swift can't replace Obj-C code. Everyone has C++ code they need to link to. Apple has C++ they need to link to in their own APIs. So does Adobe. Microsoft. And they'll probably fix it in the future. But you can't even approach suggesting Swift is going to replace Obj-C with a straight face until that is fixed.

Now look, I'm not trying to argue against Swift here. It's a valuable language to use and learn. This isn't a desperate "Obj-C forever!" post. But if you think Obj-C is going anywhere in the next decade or two... It can't. Apple will continue upgrading it, and continue supporting it, or else they're going to end up putting themselves in a corner where they can't even maintain their own software. That's not opinion, that's realism. It's knowing when a tool is right for a problem. And we're nowhere near Swift even being able to entirely replace Obj-C in usage.

Heck, the last Xcode beta even shipped with some upgrades to Obj-C. So I don't even need to argue that point. It's not a question of if Apple will keep advancing Obj-C. They are.

Re:Even Apple is abandoning Objective-C

[msobkow]

The fact that Apple has to maintain internals using Objective-C does not conflict with the fact that they're pushing platform developers to use Swift. There are pieces of Apple's stack written in C, C++, and probably even other languages as well, seeing as the vast majority of their code base comes from open source.

Of course Apple hasn't said Objective-C is a dead end. There would be a revolt and a mass fleeing from the platform if they did that.

But they sure as hell aren't encouraging people to stay on Objective-C instead of moving to Swift.

Are you sure you're on the same internet as the rest of us? I've read several articles and summaries (including on Slashdot) that have made it clear Apple wants people to use Swift.

Oh, wait. Never mind. Apple person. You don't deal with the same reality as the rest of the world.

Re:Even Apple is abandoning Objective-C

[maccodemonkey]

Of course Apple hasn't said Objective-C is a dead end. There would be a revolt and a mass fleeing from the platform if they did that.

...from their own developers? Again, out of the whole community, they have the largest Obj-C source base. If they abandon Obj-C within the next 10 years, they won't be able to ship anything. And it's going to take at least a decade to rewrite everything, if that was even their goal. During which time they ship no features. Apple can't abandon Obj-C because they need to use Obj-C. If they abandon Obj-C, they abandon Mac OS X and iOS. And they will be done in the market. And given that new API is still written in Obj-C, that's a process they haven't even started yet. In April they're shipping a brand new hardware platform that still runs on Obj-C.

For a past data point, Microsoft said with Vista they were going to rewrite Windows in C#. How did that go? Replacing an entire language is simply not realistic. If you're an engineer, you should know that.

Furthermore, once you're talking about the pain and suffering in moving everything to Swift, maintaining Obj-C looks like a far easier and more desirable costume. And that's what Apple is doing.

But they sure as hell aren't encouraging people to stay on Objective-C instead of moving to Swift.

I've talked with engineers on the Swift team who've said that's not the intention (and are wondering why the public thinks that). But please. Do go on.

I've read several articles and summaries (including on Slashdot) that have made it clear Apple wants people to use Swift.

"I've read articles from other people who think they know what they are talking about, and they wrote something that they think is right. Look at me! I'm such an expert!"

Oh, wait. Never mind. Apple person. You don't deal with the same reality as the rest of the world.

I... deal with the realities on the Apple platform?

Re:Even Apple is abandoning Objective-C

[msobkow]

http://ask.slashdot.org/story/14/11/28/2148254/ask-slashdot-objective-c-vs-swift-for-a-new-ios-developer

http://ask.slashdot.org/story/14/09/26/2247211/ask-slashdot-swift-or-objective-c-as-new-ios-developers-1st-language

From http://www.raywenderlich.com/74138/swift-language-faq:

So you can still use Objective-C. However, Apple seems to be encouraging you to use Swift for any new development, while not expecting you to go back and re-write all of your Objective-C code.

From www.archer-soft.com/en/blog/technology-swift-vs-acobjective-c-pros-and-cons:

Swift was created in order to replace Objective-C, however, Swift is capable of working alongside Objective-C while using Cocoa and Cocoa Touch frameworks.

Re:Even Apple is abandoning Objective-C

[msobkow]

Five minutes with Google and no Apple-rosy glasses.

Most Linux libraries are built with C. Does that mean you have to use C to program Linux? Of course not.

So too with the existing Objective-C libraries. The language used to write a library is irrelevant; what matters is the language bindings the programmer uses to invoke the libraries.

Re:Even Apple is abandoning Objective-C

[maccodemonkey]

http://ask.slashdot.org/story/14/11/28/2148254/ask-slashdot-objective-c-vs-swift-for-a-new-ios-developer

http://ask.slashdot.org/story/14/09/26/2247211/ask-slashdot-swift-or-objective-c-as-new-ios-developers-1st-language

From http://www.raywenderlich.com/74138/swift-language-faq:

So you can still use Objective-C. However, Apple seems to be encouraging you to use Swift for any new development, while not expecting you to go back and re-write all of your Objective-C code.

From www.archer-soft.com/en/blog/technology-swift-vs-acobjective-c-pros-and-cons:

Swift was created in order to replace Objective-C, however, Swift is capable of working alongside Objective-C while using Cocoa and Cocoa Touch frameworks.

None of which are first party sources. Please cite one.

Here, I'll help you out. Here is a quote from one of your own sources:
"To quote Apple, “Objective-C is not going away, both Swift and Objective-C are first class citizens for doing Cocoa and Cocoa Touch development.”"

You're purposely digging around Apple's own statements that Swift and Objective-C are first class citizens.

Wait, first class citizens? That sounds a lot like what I said in an earlier reply. Hmmmmmm.

Re:Even Apple is abandoning Objective-C

[msobkow]

The whole question of Swift vs. Objective-C is irrelevant, anyhow. The original article is asking about C++ vs. Objective-C.

Their initial target platform is Linux, not MacOS or iOS.

Which brings me back to my original point: Objective-C is a dead-end.

Re: Even Apple is abandoning Objective-C

[maccodemonkey]

Which brings me back to my original point. There are millions of lines of Obj-C out there, that will need to be maintained or improved for decades. Even if developers wanted to, Swift isn't compatible with a lot of use cases. And brand new Obj-C code is being written and shipped today by companies including Apple. Yes, Swift is a great new addition, but Obj-C will be around for few decades more.

By no measurable metric based in reality is Obj-C dead. Obj-C is as dead as Visual C++ became when Microsoff rolled out C#, in that it's not. Multiple languages is great. This isn't some Highlanderish situation that you're trying to make it out to be.

If OP learns Obj-C he's have a skill valuable for many many years to come. And I'm not saying that's what he should do. C++ is valuable too. But it's not a dead end, and if you say that, you really don't understand the realities of maintaining existing products, or the use cases of Swiff va, Obj-C at this point. I have projects still where Swift wouldn't be able to replace the Obj-C source entirely even if I wanted it to.

Re:Even Apple is abandoning Objective-C

[countach]

"Apple has not shipped a single API on Mac or iOS written in Swift. "

Apple has specifically designed Swift so that if the day comes that they are writing APIs in Swift instead of Objective-C, YOU WON'T EVEN KNOW. They have the same internal object model and memory layout. They are basically the same language with a different syntax. (Not quite, but it's not too far off).

And while Apple might not have declared Objective-C dead, people who've seen how Apple operate before can clearly see the writing on the wall.

Re:Even Apple is abandoning Objective-C

[CraigCruden]

What???? As far as I was aware... Swift is language which depends on LLVM (which is not a virtual machine as in jvm). This is the same as Objective-C which is now compiled using Clang (many many years since gcc was replaced with clang). LLVM is just a pseudo assembly language which is compiled down to machine code. It is not a virtual machine. It is compiled down just like Objective-C. When using the REPL or as with Objective-C when it is being run inside xcode I believe it is in jit form, but this is no different than Objective-C.

Re:Even Apple is abandoning Objective-C

[david_thornley]

Of course Apple hasn't said Objective-C is a dead end. There would be a revolt and a mass fleeing from the platform if they did that.

Apple has done that sort of thing several times in the past. They may have angered some developers, but there were plenty left.

Remember when we were supposed to use OpenDoc? Hypertalk? Java? Or haven't you followed Apple development as long as I have?

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)

Re:C++ - but look at C# as well

[Shados]

Generally when people say compiled language, and they refer to things like Objective C and C++, they usually mean compile to as close to native code as possible. I love C#, but its fairly obvious that bytecode languages were not options this time around.

C++/Boost is their best bet.

Re:C++ - but look at C# as well

[Touvan]

MS is switching C# to an AOT system using their very mature C++ backend. Unity3D is doing something similar, and Xamarin does AOT on iOS already (though not through a mature C++ backend). It's still memory managed, but going forward it will be as compiled as anything else.

Re:C++ - but look at C# as well

[phantomfive]

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:

But stay away from Entity Framework and Nuget. EF is slow, and Nuget....well, even Microsoft evangelists criticize it.

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

If you do want to do cross-platform development, you should stay away from advanced C# features like code-contracts. In fact, if you really want to do that, then you should have at least one person developing on Linux, so you stay aware of all the little incompatibilities.

Re:C++ - but look at C# as well

[Shados]

Entity Framework being slow isn't the problem with it. The performance of an ORM only really depend on 2 things. The time it takes to do the mapping, which is trivialized by the actual queries and is really a micro-optimization, and the SQL generated.

The later is fine in almost all of the mainstream ORMs, and the only real issues come from N+1 queries, and not aggregating queries that can be by using the context and futures. ActiveRecord based ORMs have issues because of the way context vs model objects is managed but they can still handle it fine, the N+1 problem is almost always a developer thing.

The reason Entity Framework sucks is that its API is poorly documented, so short of reading the code, no one knows how to do things correctly, a lot of its features are not exposed through the tools, thus encouraging using the RAD/shitty ways of doing things, and they pulled it in all directions trying to make everyone happy, ending up with a lowest common denominator.

You can get perfectly good performance out of EF, it has all the features an ORM needs to achieve it. Its just hidden/awkward/changes all the time/forces you into writing shitty code.

Re:C++ - but look at C# as well

[phantomfive]

The reason Entity Framework sucks is that its API is poorly documented

That is true too.

You can get perfectly good performance out of EF, it has all the features an ORM needs to achieve it.

I don't believe it. I've worked pretty hard at it (one example, inserting a large number of rows into two tables, one that has a foreign key into the other table, can take 1000 times longer than simple SQL queries).

Re:C++ - but look at C# as well

[Shados]

That will heavily depend on how you do it. If you have a 1 to N, and insert the object trees one by one, you're going to get a crazy amount of back and forth. The amount of queries will be the same, and similar to the ones you do manually, so there won't be any meaningful differences there.

The main difference is that you're likely to do "Insert 1 in master, 5 in detail, 1 in master, 5 in detail", batching them in groups of 1 and N, when the correct way is to insert all the rows in master, then all the rows in details (batching in smaller groups if transaction size is a problem).

EF can handle that scenario just fine. Its just not that clean.

That's just understanding how an ORM work, and all ORMs have these issues. You get used to working around them. (You'd have a seizure seeing what Rails Active Record does, yet people use it in petabyte scenarios.)

Re:C++ - but look at C# as well

[phantomfive]

The main difference is that you're likely to do "Insert 1 in master, 5 in detail, 1 in master, 5 in detail", batching them in groups of 1 and N, when the correct way is to insert all the rows in master, then all the rows in details (batching in smaller groups if transaction size is a problem).

I'll try it out.

Re:C++ - but look at C# as well

[mosdave]

I don't disagree about avoiding EF, but Nuget? It has its quirks, to be sure, but it mitigates way more friction than it creates. Calling Skeet's brief comment a criticism is a bit disingenuous, I think.

Re:C++ - but look at C# as well

[phantomfive]

For almost a decade, I hadn't had a corrupt Visual Studio project file. Start using nuget, and I did. Nuget adds much more friction that it removes.

Re: Classic?

[Em Adespoton]

Indeed -- learn LISP. Lambda variables, recursion, all atoms being true objects. Then you can redefine the language to pretend to be any of the other HLLs out there.

Problem is, all the lessons that were learned with LISP have since been forgotten and are doomed to be made again and again.

Clear Winner

[BlackHawk-666]

You should learn c++ unless your real intent is to write a lot of software for an Apple only environment in a language they are looking at deprecating.

You can get a c++ build chain for pretty much any platform worth working on, and those without it will have a c build chain. There are literally billions of lines of c++ code out there, working in every possible environment. Programmers are churning out millions of more lines every year. You will never be out of work if you are a c++ programmer.

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++ important on Apple too

[countach]

Err, well you've got to write the core code in _something_, and why not Objective-C? You can compile it for any platform you like, and I'm a big proponent of sticking to one programming language for everything. You lose a lot by shifting between paradigms and being unable to pass objects around between different layers. Most likely Apple's iTunes for Windows is written in Objective-C and it works for them. Objective-C is a pretty thin layer around C, and at least in the old days, just preprocessed it into C, so it isn't inherently less portable than C.

Re:C++ important on Apple too

[BasilBrush]

C++ is also important when targeting Apple.

Not quite. Although you can compile C++ as part of an OSX or iOS project, there's no point - other than using someone else's library. The parts of projects that aren't Obj-C tend to be C.

Why?

You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C. If you're wanting objects at the expense of speed, then you wouldn't stray from Obj-C in the first place.

Re:C++ important on Apple too

[tlhIngan]

Not quite. Although you can compile C++ as part of an OSX or iOS project, there's no point - other than using someone else's library. The parts of projects that aren't Obj-C tend to be C.

Why?

You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C. If you're wanting objects at the expense of speed, then you wouldn't stray from Obj-C in the first place.

Technically, you can just call C code straight from ObjC - ObjC code compiles C code just fine (unlike C++, which cannot compile C code).

Whether that code is in the same file or different doesn't matter - ObjC is a superset of C.

Re:C++ important on Apple too

[swillden]

You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C.

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

Unless you're concerned that you may need to target a platform not supported by a decent C++ compiler (which is really rare, given that gcc is basically everywhere), the only reason to choose C over C++ is personal preference or concern that some of the users of the code may not know C++.

Re:C++ important on Apple too

[perpenso]

You lose a lot by shifting between paradigms and being unable to pass objects around between different layers.

That is not my experience. It feels quite natural and automatic to think Obj-C when doing UI code and think C++ when doing core code. Plus passing objects around seems a non-issue. One can use C++ structures and classes in Obj-C code and Obj-C objects tend to be those interfacing with the UI code, objects of no interest to the core code. And if an Obj-C object is input from the user its trivial to convert to an ordinary UTF8 string, int, etc.

Most likely Apple's iTunes for Windows is written in Objective-C and it works for them.

That assumes one uses the gnu toolchain. When I write portable code I like to build it in Apple Xcode, MS Dev Studio and with GNU. Different warning can be useful and well as running regression tests on output from these three different code generators.

Re:C++ important on Apple too

[BasilBrush]

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

1) Good but not as good as C.
2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?
3) Indeed. So virtually no one uses it in this scenario.

Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.

Re:C++ important on Apple too

[perpenso]

All these things are usually best served by C.

Untrue. As far as my C++ code goes its kind of "light" on the use of templates, classes, etc. I don't use them because they are available, I use them when they make sense. My code is sort of C'ish in this respect.

If you're wanting objects at the expense of speed, then you wouldn't stray from Obj-C in the first place.

Untrue. Obj-C is not as portable as C++. Even when not targeting MS Windows I like to compile the core code and run regression tests using MS Dev Studio. Yet another set of warnings, yet another code generator to help spot bugs. Plus I also tend to write code so that someone else can eventually maintain it. Obj-C is a niche language, C++ has a much broader user base.

There really is no downside to using C++ in core code rather than Obj-C.

Re:C++ important on Apple too

[BasilBrush]

Obj-C is not as portable as C++

And C++ isn't as portable as C. Or as efficient.

There really is no downside to using C++ in core code rather than Obj-C.

But there are downsides to using it in this capacity rather than C. Which is why few do so.

Re:C++ important on Apple too

[david_thornley]

You can run standard C++ on any modern general-purpose processor. It doesn't have a standard ABI, which C has in practice, but if you're writing your code you just use one C++ compiler and you're fine. Technically, C is more portable. If you're talking about programming a computer or a phone or something like that, it's just as portable.

C++ can be written as efficiently as C, since you can make any C program into C++ with minor changes. C++ also has facilities that make it easier to write efficient code than in C; std::sort is not only easier to use than qsort(), it's more efficient.

Re:C++ important on Apple too

[swillden]

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

1) Good but not as good as C.

In most cases these days it's a distinction without a difference.

2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?

I see this differently. Obj-C has the objects I need to interact with the framework. C++ has the speed, compatibility and expressive power I want. C has speed and compatibility, but lacks expressive power, which creates a lot of tedium and loses a lot of safety.

3) Indeed.

We agree on something :-)

So virtually no one uses it in this scenario.

Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.

I haven't really done much on Macs, but I did a lot of work on NeXTstep back in the day, and C++ was quite common in scientific computing there. Actually, what I saw a lot of was "Objective-C++"... they may have grown further apart, to the degree that this no longer works, but in the early 90s gcc allowed you to mix Objective-C and C++ constructs freely in the same code. So a common approach was to build everything in an OO fashion, but to choose between Objective-C and C++-style classes based on performance and flexibility tradeoffs. The result required you to be fluent in both, but that really just means being fluent in C++ because a C++ programmer can learn Objective-C in a day (which is something I respect about the language).

Re:C++ important on Apple too

[perpenso]

Obj-C is not as portable as C++

And C++ isn't as portable as C.

Straw man, the question is Obj-C v C++ not C++ v C. And for nearly any practical sense you are mistaken, its rare to find an environment that has C support but not C++.

Or as efficient.

Speaking as an assembly language programmer, you have been misinformed. Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's. Can an STL class be overkill, yes, but the STL is about convenience and correctness not performance, and a programmer's misuse of such a library is another programmer's error.

**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer. To be honest when dealing with extremely time critical code if C++ is going to be replaced I will replace it with assembly.

Limiting your options to C in the non-time critical portions of you code is completely unnecessary. You can write the C'ish code I mentioned above or you can write pure C code if you with for the minor amount of code that is time critical.

There really is no downside to using C++ in core code rather than Obj-C.

But there are downsides to using it in this capacity rather than C. Which is why few do so.

Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects." http://google-styleguide.googl...

Re:C++ important on Apple too

[perpenso]

Speaking as an assembly language programmer

You can't claim authority here. I was programming assembler as far back as 1983.

Me too, 6502 (Apple II, C64) and PDP-11. 68K too via Apple II coprocessor boards, maybe that was '84. Its how we did our earliest Mac development, couldn't afford a Lisa. Eventually 68K on Mac once native development was an option. And a ton of x86 throughout the late 80s and 90s, less so in the 2000s. A little bit of PowerPC in the 2000s too. Recent years just doing it for fun or looking at the generated code from compilers.

Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's.

What you mean by "misused" here is using the C++ parts of C++. Because if you do, you will almost certainly be slower than C. For example virtual functions require an extra level of indirection over C function calls.

You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.
(2) If you need the abstraction/indirection then you are simply doing your own indirection manually in C code. Been there, done that, in the late 80s when C++ was too new and object oriented methodologies would greatly benefit the application at hand.

**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer.

And when it doesn't matter then no need to stray from Obj-c. There's no reason to have 2 OO languages in a project.

I've proven this wrong already. Read past posts regarding portability, ex MS Dev Studio.

Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects."

Shut the fuck up. I've already said more than once that the only reason people use C++ in iOS or OSX projects is when they are leveraging a library that's in C++.

You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++. Plus you are doubly wrong again since people also use C++ in Apple targets for portability.

Re:C++ important on Apple too

[BasilBrush]

For example virtual functions require an extra level of indirection over C function calls.

You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.

If you're not using inheritance then you won't use a virtual function. (Did you read what I wrote?)

If you need the abstraction/indirection then you are simply doing your own indirection manually in C code.

Not necessarily. Just because you might do things with objects in C++ doesn't mean the code would be written as pseudo objects in C.

You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++.

Portable libraries. It makes no fucking difference whether the library was written within the same conglomerate.

Plus you are doubly wrong again since people also use C++ in Apple targets for portability.

Are you hard of thinking? That was the one exception I made. Using portable libraries. However if the library intended to be portable starts on OSX, then it's virtually always written in C.

Re:C++ important on Apple too

[perpenso]

For example virtual functions require an extra level of indirection over C function calls.

You are wrong, doubly wrong actually. (1) If the class is not using inheritance you don't get the indirection.

If you're not using inheritance then you won't use a virtual function. (Did you read what I wrote?)

Yes, I'm rejecting the notion that C++ code inherently involves inheritance. Note my reference to minor use classes and templates being quite useful and not performance hindering.

You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++.

Portable libraries. It makes no fucking difference whether the library was written within the same conglomerate.

It however does disprove you claim that C++ isn't being used to a large degree.

Plus you are doubly wrong again since people also use C++ in Apple targets for portability.

Are you hard of thinking? That was the one exception I made. Using portable libraries. However if the library intended to be portable starts on OSX, then it's virtually always written in C.

I'm not referring to libraries, I'm referring to the app's core code itself.

Also many libraries are merely C for legacy reasons. For new code, refer to Google's use of C++ again.

Teenagers

[Anonymous Coward]

SF companies are like the fashion industry with models- they only hire people under tha age of 15 or something.

Also, they code everything in Javascript. Why Goigle's entire company is all Javascript. They even recoded Linux in Javascript! That's how fucking smart they are!

Good ties in FOO

[manu0601]

Submitter wants a "widespread compiled language that has good ties into FOSS".

What about plain old C? Otherwise, second best choice seems C++

Headless applications in Objectionable-C?

[Lumpio-]

Does anybody actually do that? Isn't the only reason that language isn't extinct the fact that you can do fancy OSX/iOS apps with it? C++ all the way.

Cross platform development.

[Savage-Rabbit]

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.)

I would only bother with Objective-C if I was anticipating having to develop a lot of code for OS X or iOS which might be worth your time since there is money to be made there and IMHO it is a fun language to code in. There is a FOSS Cocoa implementation for Linux, GNUstep but I don't know how current it is or how much cross platform development it allows. Integrating C++ code in Objective C programs (aka. Objective-C++) is as easy as integrating C code into a C++ program so for cross platform purposes you'd be best advised to write as much of your business logic in C++ or even C and use more platform specific languages like Objective-C for view and controller logic. Basically write as much in C++ or C as you can since both can be used in Objective-C apps. That way, if you also want to, say... have an Android version you could write Java wrappers for your C/C++ code. Finally be very careful about what system calls and libraries you use. Just because something is available on Linux does not mean it is available on OS X, the other *NIX'es or Windows. I have all to often seen people end up with egg on their faces after spending significant amounts of time developing something on Linux and using everything Linux offer with wild abandon only to find out hat several key functions or even entire libraries are not available on other target platforms like, say Sun OS or AIX or that even if these are available they behave in a totally different way (example: Lex/Yacc). When doing CP development, even if it is just across multiple Linux/Unix platforms, it pays to write unit tests and regularly compile your software and run the entire test battery on target platforms other than the one you do most of your development work on (which is likely to be Linux).

Re:Cross platform development.

[drinkypoo]

ntegrating C++ code in Objective C programs (aka. Objective-C++) is as easy as integrating C code into a C++ program so for cross platform purposes you'd be best advised to write as much of your business logic in C++ or even C and use more platform specific languages like Objective-C for view and controller logic. Basically write as much in C++ or C as you can since both can be used in Objective-C apps.

Poster is looking to find out which one language to use, so your suggestion is out of line. However, it's probably the most useful and informative text in this whole thread. (There have been some other mentions of the same fact, but none of them have been as explicit.) Here's the upshot: If you want to be able to use your code elsewhere in the future, use C++. Which means, basically, you'd have to be insane and/or sociopathic to use ObjC. It may cause you problems, and it will certainly cause anyone else problems in the future.

Wrong two choices

[thisisauniqueid]

This is like asking "which medical technique should I use for treating headaches, trepanning or inhaling mercury vapors?"

I'd go for C

[Zobeid]

Yes... You can do OOP in C. With todays toolchains, libraries and techniques, C is more viable than a lot of people give credit for.

I personally have always disliked C++, and I know I'm not the only one. I've been OK with Obj-C, but... It is a bit eccentric, and it's probably on the way out with Apple now promoting Swift.

C, on the other hand, is eternal and evergreen.

Re:I'd go for C

[halivar]

C, on the other hand, is eternal and evergreen.

Yeah, but at this point, isn't C++ also? C predates C++ by 10 years, but that gap looks smaller and smaller as time goes by, and both are in continue active development and use.

What is the goal?

[140Mandak262Jamuna]

Why do you want to learn a classic object oriented compiled language?

If you are planning a career switch, C++. No question.

Just to teach something to you to do some hobby work? Pick something and go. You are over thinking it. You don't need the best in class, no pun intended, just anything will do.

If you are planning to create a course to offer to some college students, go with Java or something

If all you want is to troll the slashdotters to argue endlessly, congratulations, you have done it. Let me add my contribution too, emacs man! Use emacs. vi sucks.

The best of both worlds!

[Yaztromo]

Objective-C++!

(Yes, there is such a thing. And yes, I'm being facetious.)

Yaz

Re:The best of both worlds!

[Drishmung]

Well then, why not Object Oriented COBOL? (In COBOL idiom, ADD 1 TO COBOL GIVING COBOL.)

Not hating on C++, but something to consider

[Anonymous Coward]

C++ and Objective C are very different languages, as most of the posters would agree. And I would agree that Objective C (although fully supported on both the C++ and Clang tool chains) is not as cross platform. That's because most of the libraries that make Objective C useful are only available on the Mac. Objective C, however, has a completely different approach to object orientation that's closer to Smalltalk. It has a message sending style as opposed to the method oriented approach of C++. For example, you can serialize a method invocation on Objective C, send that invocation across a wire, and invoke it on a remote object. I think (oddly enough) that Objective C gets a bad rap as an Apple technology. And although that's the only place where it currently flourishes, it has an interesting approach to OO that is worth looking at.

both?

[shadowrat]

I picked up objective-c when ios became big. it's fine and all, but what i find myself doing is writing as much as i can in c++ and then just calling into it from objective-c where i need to. xcode will happily compile the two languages (technically i'm using objective-c++). really, even in apple's apis objective-c only gets you so far. sooner or later you will find yourself calling into c apis. heck even some of their examples only feature a rough skeleton of objective-c working with a big c library.

my advice: learn enough objective c to make an NSView and handle some events, and send that stuff right into you c++ api asap.

C++ is superior: more strongly typed

[Chuck Messenger]

There is a continuum of langauges along the "how strong is the type system" scale. C++ is on the strongest end of the scale. (And here, I have in mind C++11). Let's say C++ is a 9/10. Let's say a scripting language like Ruby is a 1/10. On the scale, Objective C is maybe a 7/10.
A strong type system is essential for high-producitivity, low-error programming of complex projects. If you are programming smaller things, a less-strong type system can be a benefit, due to the speed of programming and the flexibility it gives you. But once you're talking about more than a few hundred lines, you're well into strong-typing territory. At this point, you should think thru your design and start throwing down a type system!

Re:C++ is superior: more strongly typed

[WorBlux]

And haskell is about 10/10, being able to expressively type functions, and make custom types. Point being some may find 7/10 good enought to catch stupid errors, while letting the code be a bit terser and more readable. I'm not sure the tradeoff is at the couple hundred lines territory, as there are often ways to add in additional type restriction in dynamicly typed languages, and you may just want to start with a quick and dirty prototype as a template for the final version.

Re:C++ is superior: more strongly typed

[Required Snark]

Actually, Haskell goes all the way to 11,

Re: C++ is superior: more strongly typed

[dirthead]

Ruby is very strongly typed. It is just lazy about it.

Re:C++ is superior: more strongly typed

[david_thornley]

You seem to be advocating not only strong but static typing, which are different things. Any Common Lisp entity knows what type it is, for example, and you can't say that about C++. However, the C++ compiler knows what type something is, while in Common Lisp that's optional.

A really strong static type system is incompatible with C++'s OO system, in that, given a Base and Derived class, the compiler won't know if a Base * is a Base * or a Derived *, and that's essential for polymorphism.

Most of C++'s type weaknesses were inherited from C. If you avoid C-style casts and unions (usually only necessary in fields where type safety is not a concern), C++'s type safety increases markedly.

Re:C++ is superior: more strongly typed

[Chuck Messenger]

Are you referring to dynamic typing? In my (perhaps simplistic) view of the world, there is dynamic typing and static typing. "Strong" typing, to me, is static typing.

What other kind of typing is there? I'd be interested to hear about Common Lisp's class system, which seems to be in-between static and dynamic somehow.

I agree with you about C++'s weakness (one example) - that you need to use a pointer (uggghh!) in order to get polymorphism. That's an example of why C++ doesn't score a 10/10 on the scale.

Which to choose

[crbowman]

Pick Objective-C. The language is small and simple to understand. If you're already a good programmer with knowledge of C you can learn it in 2 weeks to a month. The frameworks will take longer but the language you can learn in a few weeks. C++ on the other hand will take you forever to learn, it's a large complex language.

Re:Which to choose

[david_thornley]

You can't learn object-oriented programming as a way of thinking in a month. At least I couldn't come within an order of magnitude of that, and I'm very good at picking up new programming ideas.

Re:Objective C, of course

[Anonymous Coward]

I have never played with Objective C, but I have with C++. Nothing can be worse than that wretched language. It subsumes in itself the worst of C and the worst of the OO paradigm.

Then you never programmed in EDL for the IBM Series/1. EDL was an interpreted Assembler. Written for a machine that combined all the worst features of the PDP/11 and System/360. "Bank switched memory? Why yes sir!".

Ada 2012

[darkwing_bmf]

If you're picking from scratch, check out Ada 2012. It has all of the power of C++ but it is a "safer" language designed to produce more reliable software (i.e. the kind that can be used in bullet trains and airplanes). While aerospace and defense are its reasons for existence, you can produce high quality desktop software as well.

http://www.ada2012.org/

ObjC++

[staalmannen]

Out of curiosity: is there a point with ObjC++ or are the advantages of C++ and ObjC redundant? Secondly : is C++ still a superset of C89 or have they diverged further?

Why?

[Anonymous Coward]

Don't use OOP at all.

choose your lens mount carefully

[epine]

You can always find another language that is better at it on every single aspect you look at. Jack of all trades master of none.

Master of Jack is the one thing where no other compiled language triumphs over C++.

If you're sure on day one that there are language features your project will never need (on any project fork)—cross my heart and hope to die—then go ahead and pick a less cluttered language better suited to your constrained subdomain.

What you're really saying here is that you'd rather work in a constrained subdomain—pretty much any constrained subdomain—than hump around on crowded streets hulked up with a universal camera bag (source Mumbai-based photojournalist Dilish Parekh).

Sigh

[Cafe Alpha]

I'm not happy with any language that's available, but that's because I have interests in hard to program stuff.

I have lots and lots of experience with C++, but I wouldn't recommend it, except as a form of torture. Java too, is gets in your way far too often, though it's better than C++.

To me, objects are a way of organizing APIs, so I DO like OO...

What to write it in depends on what features you need. Do you need it to be fast? How fast? Do you need to take advantage of multiple processors? Do you need to share data between them?

Is programmer time more important than running speed?

Is reliability more important than programming time?

One system I'm enjoying these days, though it's far from perfect is Lua, through the amazingly good trace compiler/jit Luajit.
It is every inefficient in terms of memory. It doesn't support multiple threads. It doesn't even have standard object system, though it's not hard to implement a prototype based one in it... But it's kind of like programming in Self or Ruby with the complexity knob turned all the way down.

It also has the advantage of running on everything. There's even an ARM version of the JIT.

If you don't need the speed, Python doesn't look too bad and has lots of libraries.

If you need something that can be data-center-sized then find a .net language or java... There's a lot of choices under .net and it probably scales the best. Depending on what I was trying to do, I might use F# or ClojureCLR or IronPython...

The best OO language that time forgot is Dylan. I'm disappointed that Apple never really finished developing it.

The Rust Language

[Trevelyan]

I have been mulling similar question for myself for some time. i.e. where should I spend my limited hobby time: learning Obj-C or C++?

In the last few months Rust has caught my attention. Even then it's not yet at verstion 1 (at time of writing its at alpha-1), I really like the concept and what they are try to achieve with the language.

My comment will probably be burried, but if you do read it, spend a few minutes wondering around their web site. For exmaple their 30 minute introduction to Rust.

Re:Abandoning Objective-C is a bad choice of words

[CraigCruden]

Yes, Apple has millions of lines of code and yes Apple is not going to re-write all that code in the next couple of years.... but there is no denying that Swift is more productive than Objective-C easier to maintain. Apple is not going to say, Objective-C is dead but it is now very much a "legacy language" where you maintain the code but new stuff will be written in Swift. Swift though is a new language and it still has maturing to do. Being that Apple is both the user and creator of the language, most if not all that Swift may not be "able to handle" right now will eventually be added. If there is something that for performance reasons is not there yet - it can still be written in Objective-C and used in a Swift project.

If you are developing for the Mac OS X or iOS platforms - you would chose Swift from this point going forward. You would maintain your legacy Objective-C code until the point where it makes sense both business and risk-wise to rewrite it as part of some upgrade. As far as Linux, Apple has made no commitment (yet) on when/if they will open-source / multi-platform it so it is moot for the purposes of the OP. To be quite honest the original requirements for the OP seems to be centered around that he missed out on some fad/direction and now is asking what he should pick-up but only wants to use "classic" languages, but without any real clear reason on what his "needs" are. This is backwards. Languages are tools, you don't pick a tool first. It would be akin to picking a hammer then turning and saying, good... got that out of the way.... now I think I will fix my watch.

Re:you can do osx and ios in c++

[CraigCruden]

You have your history mixed up. They are different directions from the same root language, but Objective C is not a "superset" of C++. C++ (preprocessor for C) started as C with Classes. Objective C was originally a preprocessor for C which tried to patch in Smalltalk ideas ontop of C. One is not a superset of the other... but they both have the same C roots. It is not much different than having all the different languages compile down onto the jvm, they are not supersets or subsets of each other - they just use the jvm. It provides a transportable platform onto which to compile/run the "compiled code". Creating preprocessors on top of C gave similar advantages to both of these "new languages".

Re:I have done lots of both and say C++ absolutely

[countach]

The [[[][]]][] in Objective-C are an extremely simple concept to grasp. The same can't be said for all the >< in C++.

I should think the choice is obvious

[DrXym]

I'm not even sure what a "classic object oriented compiled language" is meant to mean or why it should be the criteria for programming something, but given the choice of C++ or Obj-C then C++ is the answer in virtually every case. Obj-C only makes sense when targetting iOS / OS X or some niche like OpenStep and whatever merits Obj-C might have as a language it would be insane to use it anywhere else.

Objective-C is a mongrel

[Theovon]

I like SmallTalk, and I like C. However, their syntaxes are very different. Objective-C mashes them together in a way that results in a very inconsistent feel to the syntax. C++, on the other hand, is just a logical extension of C syntax. Sure, there are some advantages to Objective-C's message passing approach. Well, if you consider silent failure when you pass a message to a null object to be an advantage.

Objective-C predates C++, and it shows. Someone shoehorned in OOP in a way that was borrowed from a totally different philosophy. Then Stroutrop came along and did it right. Some people may have complaints about C++ at an abstract level, but at least the language is internally consistent (or more so than Objective-C anyway).

Re: Classic?

[dargaud]

Then you can redefine the language to pretend to be any of the other HLLs out there.

I won't touch a language that does this for the simple reason that anybody writes his own 'language' with it and nobody can read what anybody else does. And while I'm at it, the whole "there's more than one way to do it" is totally counter productive since 10 programmers would produce 10 different codes and few would understand the logic of the others easily. Gimme a strict language with only one way to do it and my code will be the same as my neighbor and that's great for readability.

Silly Dichotomy

[ChaoticCoyote]

The question is silly. Which language to choose depends on the task at hand, not arbitrary religion. I was using C++ when it was "C with classes", wrote books and articles about it -- and my answer is to use the tool best suited to a given task and target platform. I've used Objective C when it fits my goal. I dislike questions asked only to invent false reasons for making a choice.

Neither. Java.

[drolli]

Java is nowadays a "classic" compiled OOP language.

A variant of C++

[Misagon]

C++ isn't really one language. The language has evolved in several ways over the years. C++11 is vastly different from the first incarnation.
In real-world programming you might therefore encounter many different styles: C++ used as a better C, C++ but with the coding style dictated by the C libraries that are used, C++ as "C with classes", C++ with STL, C++ with STL and Boost, and then C++11.

I would suggest C++11 or at least C++ with Boost. C++11 is the most modern, and shares some traits with other modern languages such as C#, Python and Ruby but which older versions of C++ lack. Also, several of the more recent additions to C++'s standard library have come from Boost.

C++ is also an incredibly complex language, with many workings that are more or less implicit. An assignment, parameter passing or return could involve several calls to virtual functions into the classes being used.
But once you have learned the philosophy behind programming in C++ and how to do it correctly, you will find that C++'s way is very powerful.

Objective-C is like "C + Smalltalk", and is mainly used by Apple because of historical reasons.

C++ All The Way

[ClayDowling]

My own experience has been that C++ is an excellent choice for the work you're interested in. It's full of pitfalls, but it's also full of excellence.

Start with Stroustrup's "The C++ Programming Language" and move on to Scott Meyers' Effective C++ books. Stroustrup makes picking up the language easy and natural. Meyers helps you around all the pitfalls so you can come up with elegant solutions with a minimum of effort.

Don't dismiss boost. As others have said, it's a bit of a minefield, but it also has a lot of well implemented solutions to common problems.

Qt is fun as well, and I make my daily bread using Qt. But if you're not writing a GUI app, there might be better solutions to a lot of the problems their non-GUI classes are trying to solve.

C++

[snake_case_hoschi]

* mature
* active evolution
* multi paradigm
* low and high-level programming
* widely available and supported

The future of Objectiv-C?
Well. How knows, it is not widely adopted outside of iOS and Swift is replacing it anyway because Apple has decided so.

Re:you can do osx and ios in c++

[david_thornley]

C++ never was a C preprocessor. The transformations were too complex for that. Cfront was a compiler that compiled early C++ to C, and passed on a lot of stuff intact. See Stroustrup, The Design and Evolution of C++.

Objective-C was a strict superset of standard C (at least back then; I haven't followed C evolution since C99). Its extensions were strictly syntax errors in C. C with Classes (later to become C++) was never a strict superset, as, among other things, it made "class" a keyword. The fact that the differences between C and Objective-C are so different from C syntax meant that they could be added to C++, making Objective-C++.

The O-O approaches are different. Objective-C was intended to put the Smalltalk O-O system into C, while C with Classes took O-O features from Simula and added them to C. Then, C++ started evolving into something considerably different that was mostly backwards compatible.

Good ties into FOSS? Battle won

[suy]

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.

I know plenty of open source applications, from GUIs in Qt and gtkmm to console applications and interpreters of programming languages in C++. The backbone of any Linux distribution is C and C++.

I know 0 packages in my Linux installation that are written in Objective-C. There are some, for sure, but are they widespread? I doubt it.

Re: Classic?

[david_thornley]

Common Lisp also has a macro system that's comparable to C++'s template system, but much easier to use, and the Common Lisp Object System is more powerful than C++'s. (Stroustrup wanted to include CLOS's multidispatch system, in which a method is selected for execution by the class types of more than one parameter, but couldn't find a good way to put it in C++.)

Re:you can do osx and ios in c++

[CraigCruden]

"Cfront was a compiler that compiled early C++ to C"

"A preprocessor is a program that processes its input data to produce output that is used as input to another program. The output is said to be a preprocessed form of the input data, which is often used by some subsequent programs like compilers."

It is a preprocessor. It might be an advanced one, but it is still a preprocessor.

Then, How Best To Learn?

[WheezyJoe]

The consensus has been that C++ is really useful, really powerful, but really complex, particularly in view of layer upon layer of features piled up along its evolution. How, then, to best learn how to code C++ "the right way" with its modern incarnation and features? Any recommendations?

Re:Then, How Best To Learn?

[Dutch Gun]

I think this question has been answered pretty well on Stack Overflow. C++ is too deep and complex to learn from a few web tutorials of unknown quality. Get a good tutorial book and just follow along - that's how I learned it. Then get a good reference book for more in-depth knowledge as you move past the basics.

Anything that at least covers C++ 11 is fine, as C++ 14 was more about some minor tweaks that you can learn on your own.

Be careful about learning bad habits from C++ code examples you find on the web, or in older projects. Essentially, if you see the code using new, delete, and raw pointers, it's likely outdated. You may still need these on occasion, but their use is vanishingly rare in modern C++.

Re:I have done lots of both and say C++ absolutely

[EmperorOfCanada]

Actually I hate how many people beat the crap out of templates. I love the cleaner implementations of templates when used for things like vectors but I was looking at this guy's code and he was using templates in some obtuse way to literally initialize integers. I forget how he did it but he made "int x=5;" very very complicated.

The other thing that I see people doing is the nightmare of "future proofing" their software with templates. They will write functions that only take a single input type and return a single output type and use templates so as to make this generic. Except that this isn't some API situation but just a function that will probably never ever ever ever be expanded.

I lump these people in with those who will comment like this:

// This function will get the user's ID from their username
// Takes one parameter username which is the user's username
// Returns one integer representing the user's ID.
// Returns zero if the username is not found
// CREATED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
int GetUserIDFromUserName(string username)
{
//Set the user_id to its default value
int user_id=0;
.... some kind of username lookup ...
//When complete return the user's id if any matches found. Otherwise return -1
return user_id;
}
Now these same pedantic asshats are doing the above function using templates just in case the user ID become boolean or something or the username becomes a float.

Smalltalk

[DanielOom]

C++ is the triumph of terseness over readability. If you want to play with Object Orientation use Smalltalk. Then choose a suitable language for production.

Both, of course

[slickrockpete]

If you really want to understand one then learn both while doing some compare and contrast.
Ideally you should have a few simple projects that you can implement in either language and try to maintain both.
Of course you will need to do nearly the same with C as well since they are both "based" on C.

Your understanding will be far deeper in the end.

Re:you can do osx and ios in c++

[david_thornley]

In which case the compilers in gcc were preprocessors (at least way back when), since they created assembly-language code that went to as. Java is a preprocessor, since it compiles to JVM code which is either interpreted or compiled. Any front end for LLVM is a preprocessor, since they create intermediate code that will be transformed to executables by another program.

In other words, I think your definition of preprocessor is far too general to be really useful.

Re:you can do osx and ios in c++

[rjh]

Cfront worked by translating C++ into C, which was then run through a C compiler. As such, cfront had to be abandoned in the early 90s because there were certain syntactic structures that simply couldn't be expressed in a reasonable amount of C source code.

The original poster is (mostly) correct. Cfront was a compiler only in the sense that it did a transform of one language (C++) into another (C). It was not a compiler to any extent beyond that; compiling to native code was left up to the system C compiler.

Where the original poster is wrong is calling C++ a "preprocessor for C". That's a reasonably-correct way to describe one early implementation of a C++ compilation system, but it's not an accurate way to describe the language itself.

Re:you can do osx and ios in c++

[david_thornley]

Cfront was only a preprocessor if your definition includes a full parse. Cfront compiled early C++ into C. From Stroustrup, Design and Evolution of C++, page 67:

Cfront was (and is) a traditional compiler front-end that performs a complete check of the syntax and semantics of the language, builds an internal representation of its input, analyzes and rearranges that representation, and finally produced output suitable for some code generator.

So, if you're happy calling a compiler front end a preprocessor, then, yes, Cfront was a preprocessor, and javac also a preprocessor. I still don't think that's a useful definition of the word.

Re: Classic?

[Em Adespoton]

Or, you can just agree on implementation.

See, the thing about a real object oriented language is that you define your objects, and then they only work in one manner. This means that if you're working on a project, you create your requirements documentation, and then define your core objects to match that. And then everyone who touches that code is forced to do things the same way, or else redefine the objects (which is a no-no).

The "strict procedural language pretending to be object oriented" approach is what gives unreadable code, as you end up with everyone being allowed to do whatever they want, and there's no real object model in place to constrain that.

C++ on Linux

[iamacat]

Honestly it's not the best language to learn OOP concepts. It's too complicated and makes too many compromises to be compatible with C. But if you are sticking to Linux, it will be the only choice for significant development involving UI or system level programming. On OSX, Objective C would be much easier to learn coming from C and on Android Java would be a good choice. If you wanted to just learn current best practices without regard for practicality, there are interesting newer languages like Scala.