back
79 comments
I am so glad I don't have to use C++ any more. I spent years in video games perfecting my programming skills in C++. What a waste of time. Now I'm in python I feel like I can program again.

Don't get my wrong. C++ obviously has it's place but I'm glad I'm in a different place right now.

I agree... I just wish Python's performance was closer to C++s. I use Python everyday for data analysis, etc... but I'm pretty much stuck with C++ for numerical simulations. Hopefully, the gap will become manageably small sometime soon.
I used to wish the same until I became a C# fan. If you'll ignore for a moment it's platform-specificness, it's a great compromise between Python (w/ regards to ease of use and productivity) and C++ (in terms of performance and some other things).
the good news is that it's easy to write extension modules for python when you need performance.
The bad news is, soon enough you'll realize that your entire codebase has been switched over to the extensions and Python isn't really doing anything anymore :)
People used to say something similar in games: 'Why write in C when you know you are going to have to move to asm anyway, just write it all in asm!'.

I've never seen more then 5% of c code usefully move to asm and I've never seen more then a few % of python code usefully move to a module. I am not saying it's always of waste of time it's just I haven't seen it.

But on the other hand I guess that this "different place" means that you are now no longer programming serious video games. I know how it feels like - I'm looking around for other languages all the time and even did several smaller test-games in other languages. But for the real jobs I always fall back to c++. Mostly because of the 3D libraries in my case.
Oh boy. Let the ignorant C++ bashing begin...

Before you chime in with some snarky comment about some superficial aspect of the language (like, say, the name), please try to realize that C++ is still one of the most widely-used languages in the world -- for a reason. And if you find yourself about to post something of the form "why would they add [feature X]...python/ruby/haskell/blub has had that for years", please stop and take a deep breath. Realize that it takes a long time to add features to a language that has to be standardized by committee and deployed to as many platforms as C++ has today.

You may like ruby/python/blub better, but that's a bit like saying "I like my swiss army knife better than my chainsaw". Your swiss army knife will do fine in a lot of different situations, but you're not going to cut down many trees with it. Nor would you try to open a package with a chainsaw.

When you say "C++ is still one of the most widely-used languages in the world", you're implicitly lumping C in with it. C/C++ is certainly one of the most widely-used languages, but there are whole huge categories of products that are almost never written in C++.

Some of us appreciate bare-metal systems programming, but loathe C++.

No I'm not. C++ is widely used in part because it's backwards-compatible with C, but it's not even remotely a stretch to say that C++ is one of the most widely-used languages in the world, on its own.
It's not a stretch to say that because you aren't actually saying anything. Leaving the distribution undefined as you did, we could also claim that Haskell is one fo the most widely-used languages in the world: it's certainly used more than CASL, the scripting language I wrote at McAfee in 1998.

I'm not arguing that C++ isn't widely used. I'm taking exception to the "us and them" sentiment I picked up off your comment, that the world is divided between those who appreciate C++ and those who can't hack it outside of Python and Perl. There are plenty of systems programmers who hate C++.

Where did I say such a thing? My whole point was that C++ is just another tool, like a chainsaw.

You seem to be taking this very personally.

Let the ignorant C++ bashing begin...

Speaking as someone who's spent the last 6 years maintaining large C++ applications, I'd like to think that any C++ bashing I indulged in was at least informed C++ bashing... ;)

Similar story (10 years, many gripes). But I think I'd still be in grad school if I had to rely on the blazing execution speed of Python and Perl to do all of my work. I guess I have a soft spot for the language....
I'm not sure why I would ever dick around with C++ lambdas when I could instead just write in C and a "real" high level language, like Python, Lisp, or Ruby.
It really isn't an official YC C++ thread until tptacek posts a couple bitter anti-C++ comments. ;)
Do I sound bitter?
Comparing C plus Python to C++ doesn't make any sense. The comparison would be C plus Python vs C++ plus Python.

The C++ solution would most likely be shorter, more flexible, and more secure. Personally, I fail to understand why anyone would choose to write new C over C++.

The C++ version will absolutely not be more secure; we find just as many vulnerabilities in "modern" template-y C++ code as we do in straight up C. We know how to secure C code, even if we are bad at it. Nobody knows anything about C++ security.

http://www.matasano.com/log/914/c-a-cautionary-tale-or-1-hou...

(Speaking as one of those people who did choose to write C over C++...)

People choose C over C++ because C is a simpler language than C++, something which this new standard does nothing to address.

I have difficulty handling the complexity of typical C code due to the lack of abstraction. C always winds up with huge functions and lots of hard to grasp state up in your face. C++ gives you way more opportunities to hide away complexity.
C always winds up with huge functions and lots of hard to grasp state up in your face.

That's something I've never found to be the case. Most of my C functions are 5-15 lines long. Anything more than 20 lines long is a candidate for refactoring - the unit tests will tell you if you've broken anything.

Any good programmer can write good abstraction in any language--including C.

If your functions are huge, you should rethink your design, regardless of the language.

The solution to complexity is to eliminate it, not to hide it. You've nailed the big problem with C++ right there.
Is this really true? I've never really felt that C++ was buying me a lot of brevity with its features. It was more a subject of manageability.
Modern C++ almost eliminates manual memory management. STL along with tr1::shared_ptr makes memory management almost as easy as with scripting languages. This alone trounces C.
Pass a shared pointer to a library that doesn't know how to handle it (read: almost any third-party library). Now you've got two pointers to the same block of memory under two different memory management regimes. What could possibly go wrong?
The new standard basically has nice improvements over the current one. I use C++ occasionally, when I need to write low-level code and when I think the STL will save me time over plain C. Unfortunately, the new standard won't be too useful for a while.

When the working group finalizes the standard, we get to wait for the compiler implementations to catch up. For the first five years, C++ programmers will enjoy buggy, incomplete, and mutually incompatible implementations of half of the features in the new standard. During the following three years, compilers will even out in quality, and many of them will finally implement most of the features in the 2003 modifications of the 1998 standard. It'll take over a decade for C++ lambdas to become semi-portable and acceptable in many environments.

I really hope that, in 2018, I'll be able to write low-level code in a new and cooler language. It'll probably be a Lisp. :)

I really hope that, in 2018, I'll be able to write low-level code in a new and cooler language. It'll probably be a Lisp. :)

what you really meant to say is that you hope not to write in any language in 2018

Could they have come up with a worse name than "C++0x" ?
It's a place holder. The previous standard was C++98. The last C standard was C99. C++0x means "The C++ standard that will be finalized between 2000 and 2009."
"C++" isn't a particularly great name itself, apparently they wanted to continue the tradition
Can someone actually explain what it means? I'm not a professional programmer, but I haven't seen notation like that.
Unfortunately, C++0xDeadBeef didn't work for vegetarian members of the committee.
Simple solution: Use C++3735928559 instead.
Is it just me, or does it look like a couple of these features (Automatic type deduction, Lambda expressions) seem to be borrowed from c#? And similar things are in languages like Ruby and Python.

I'm not saying that's a bad thing (or the reverse), and not saying that c# invented these ideas: I'm fairly sure that the c# designers only let in features that have already been road-tested in other, more experimental languages.

Just interesting which was around the ideas are flowing.

I had heard about automatic type deduction in C++ even before it was implemented in C#. The problem is that takes several years to get a C++ standard approved, while the C# team can just dream a feature and start implementing it in the next day.
Writing C++ I've found myself all the time implementing C# classes. When doing Win32 development C++ looks like a waste of time. If I want something to run on Windows only I can produce the same result with both languages. If I want to create a multi platform application I'll use Java or Pyhton.

C++ isn't going to die, you've got too much code out there, but its place starts to fade away

I'd disagree with "the next day" part. C#3 (with automatic type deduction and lambdas) had a beta period of about a year, to make sure that all the new features played nicely with each other.
They've been standardizing C++0x for at least three years now.
As per Bagley Shootout http://dada.perl.it/shootout/craps.html

C++ score = 27.63 Python score = 27.0

All hail the bloat-lords.

PS. Why are the additions of nullptr, and strongly typed enums a good thing? and doesn't C++ already have a NULL from C?

C's NULL sucks, because it's not a unique value and thus can be "lost" or confused with other values.

Having a distinct null which can only be arrived at by typing the characters "null" is a good thing, imo.

Can you tell a story about how NULL bit you in the ass in real code?
I remember one early version of a C++ compiler which had NULL #defined as (( void* )0), which caused all manner of fun trying to compile some legacy C code.

This was in 1999, I think.

Isn't the right solution to make C NULLs a unique value or at least get rid of them now that a better replacement is here. Seriously, have 5 different ways of doing the same thing is how perl became a hell hole for anything more than 10 lines.