The New C++: Lay down your guns, knives, and clubs

upvote

because this post is:

objective, critical, balanced and rational

nicely done

There used to be a tool

I know I will get shot down for saying this, but the tools are there. They are called Ada, Erlang and Smalltalk.

The problem is that the first is universally hated by everyone and the latter two have failed to gain enough ground outside Europe.

Google's GO language?

Take a look at Golang. Looks like the right idea set for multicore, albeit immature.

D2

I'm glad someone mentioned this. I've been experimenting with D recently and, while it seems fairly obscure, it's surprisingly good at what it claims to do. I keep waiting for it to bite me and it doesn't.

I'm going to assume two things

1) That you've been following 0x

-and-

2) It hasn't changed significantly since I last looked (which was a bit of time ago)

So:

1) Pointers, bleh, there's no reason whatsoever (that I can think of) not to be using a combination of references and smart pointers (shared_ptr is in the MS TR1 implementation now, if you don't want that you can get the whole shebang with Boost)

2) 0x brings move semantics, i.e. instead of copying the data, you transfer ownership of it to another object, have a look at it if you haven't already

3) It's perfectly possible to write platform-independent code without writing all the gubbins that go with it by using Boost and a bit of common sense. If you want to optimise it then go ahead, but only if you're advanced.

The really unfortunate thing about C++ is that backwards-compatibility thing. Unfortunately, it's too late now to start making things obsolete or unavailable, and there's not much can be done about that. Too many teachers don't talk properly about pointers and references, or RAII, or the pitfalls of constructors and the way inheritance works, and so on, and not enough companies are willing to enforce decent standards to control their C++.

I guess what I'm trying to say is that the language could do with a clean-out, but that will probably never happen. I'll have a look at D, Alexandrescu is one of my favourite C++ writers, Modern C++ Design is one of my most worn-out C++ books.

the usual trite narrow-minded drivel

"When doing real work, I'll stick with K&R C and inline assembler"

Define real work. It may be that you are only confident with the tools you have already used. It may be that the "real work" you do is all about solving small problems that do not require any degree of abstraction.

"I don't want the compiler to tell me what I can & can't do with the hardware". And if you want to program close to hardware, you are on the right track. Can you conceive of a problem space where you need to think bigger to solve a more complex problem? If not then you should stick with the mucking out.

"not a sheep." Arrogant, narrow-minded and, here's an irony, unintelligent.

What C++ templates have to do with C backward compatibility?

It is a star feature if you compare it with Java generics...

the build process

"You should not need a separate file in a scripting language to build a large project."

*Every* large C++ project I've ever worked on contained a large number of external resources that needed format conversion, precompiling, packing or other processing and the final output needed some sort of packaging or resource binding. Why on earth would tightly binding that to the C++ component make any sense at all?

A tool like make is a pretty good solution to an opened ended problem like the build process, where there's no way of even knowing what tools a dev might need to run during the build.

Decoupling the build *process* from any of the tools invoked while building is exactly the right solution. Scripted solutions like make are one of the more powerful options.

"choice of C syntax came about in the early days of the PC"

What ??!!

Here come the S-expressions! All for it.

And functional programming solved concurrency years ago. ;P

Re: syntax

My only bugbear with C++ syntax is is really more to do with fonts - if in my stupidity I've put something in normal brackets instead of curly, the two look quite similar in some default typefaces (such as the one Code::Blocks uses by default), especially when rendered in 10-point. This can lead to a lot of confused squinting before I realise what's up. Easily solvable with a little customisation, though.

I suspect the syntax could be simplified a bit if the committee felt it necessary. There's already a degree of context-sensitivity towards what each punctuation mark means - e.g. when I type a semicolon in the conditional block of a for loop, the compiler knows it doesn't mean "this is the end of the function". Personally I like using the current syntax - having plenty of different punctuation marks in play makes the code more readable once you understand what they mean. Plenty of other syntaxes (syntaces?) could use a little more variety in this area.