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.

Surely

++C++

++C++

This doesn't work syntactically. There aren't any rules for deciding on the relative precedence of ++C and C++. The fact that the language doesn't include such a rule is due to both (++C) and (C++) not being lvalues so they can't be pre/post-incremented and the question of relative precedence doesn't arise. The related C++++ doesn't work either, for the same reason. You could call it (C+=2,C-2) but it's hardly a very catchy name.

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.

@Ru

Very positive comment. For balance I'll add C++ is putrid, and I hate it.

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.

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.

Specified behavior is better than unspecified behavior

A "sky high abstracted language" helps by actually having a defined memory model. C++ does not. Regardless of the underlying hardware provided memory model, the C++ compilers can do a variety of memory reorderings. The only control you have over that is with the volatile keyword, and the prior C++ standards committee deliberately bailed out of providing better memory semantics than volatile provides. Different C++ compilers end up using different mechanisms for saying you need a memory barrier, but there's no portable way to do that.

So if you're content to write C++ code targeted at (modern) x86 CPUs compiled with gcc, you can do it. But if you'd like to write a portable library, you're screwed.

A little searching will turn up plenty of web pages with long discussions of the issues here.

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.

@AC20:46

"Define real work."

Coding close to the hardware, which should be obvious from the comment your replied to ... but for some reason you seem to think I'm not allowed to comment on that ... I mean, "stick the mucking out"? WTF?

"Can you conceive of a problem space where you need to think bigger to solve a more complex problem?"

Yes, I can. Are you equipped to understand my commentary?

"Arrogant"

I prefer "capable".

"narrow-minded"

I prefer "knowledgeable".

"and, here's an irony"

God is an iron ...

"unintelligent."

Says the AC, with no actual rebuttal to my post...

@foo_bar_baz

Most programming that isn't close to the hardware is frivolous. Think about it.

It's not the HLL that makes you a sheep, it's the mind-set (see "app stores" and the like, and what they mean in the great scheme of things).

I lost interest in managers over thirty years ago ... I'm my own boss :-)

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

What ??!!

Well, not SQL perhaps...

...but Ruby is really rather nice.

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.