The complexity is there. Trying to understand the whole language at a language-lawyer level is mind-boggling. Trying to write libraries that make proper use of the goodies is very hard.

But using C++ isn't so bad, as long as you don't try to use every aspect of it. Just use the parts you need to be able to do what you're really trying to do. You don't have to pay for what you don't use. That's good enough for a huge number of programmers in a wide variety of contexts.

There's a lot of haters that can point out a huge number of flaws. But here's the thing: Most of them, I never run into. I don't care if the move syntax is confusing; I don't use it. Maybe I never will. If I have to, then I'll care about how good or bad the syntax is. In the meantime, the parts I actually use let me get my work done better than any alternatives.

It makes me uncomfortable not to have that level of understanding for a language that's so low-level and doesn't have the "Do What I Mean" bent of say Python. I'm "meh" on C++ going forward. I invested a lot of time into my copy of "The C++ Programming Language" (3d Ed.), for C++ 98, but I can't motivate myself to get the new edition and learn in the ins-and-outs of C++ 11. It doesn't seem worth it to me. I'm really hoping Rust catches on. It's a complex language in the same vein as C++, but the bang-for-buck in terms of expressiveness relative to complexity is better, I think.

* Streamlined language with carefully-chosen syntax and keywords (there aren't 10 different meanings for "static", for instance); entire concepts have been eliminated to no apparent ill effect in building real systems. Fewer cycles allocated to the language, more cycles allocated to problem domain.

* The 95% case for associative and sequential containers is built into the language, with (for me) enormous benefits to programming efficiency.

* A streamlined and carefully orthogonalized standard library optimized for systems programming. Golang has the best-designed standard library I've ever used.

* A ruthlessly pragmatic packaging and modularity system; unlike C++, packaging is not left up to the build system.

* Build-world compilation times measured in 100s of milliseconds rather than 10s of minutes.

If I was writing, say, a generic trie library that I was hoping to get hundreds of different programmers to use, C++ would be a tempting target because of generics. But it turns out, most of the time I build projects like that, I'm really just wanking. Another benefit of Golang is that it's so stripped down and pragmatic that it subtly discourages wanking.

A lot of people would add Golang's concurrency model (share by communicating instead of communicating by sharing) and lightweight threads to this list. I like Golang concurrency too but my sense of it is that among languages designed from the jump for concurrency, this isn't that much of a unique benefit.

I'll concede this point. I can't imagine learning modern C++ as a complete beginner, even if I know why the Committee overloaded keywords like this (or worse, at least to me, overloaded symbols): the general assumption that any good new keyword has already been used as a function or variable name in somebody's code, so that changing the meaning of that word would break their code.

We'll have to see whether the Golang designers follow in the C++ Committee's footsteps on this. I remember when Java was described as a clean and simple language. I would laugh at anyone who claimed modern Java was clean or simple: adding features to the language without breaking old code is a very difficult dance.

I started out as a C programmer, mostly coded embedded stuff, and have a decent knowledge of other programming languages (Java, Python, Perl, ...), but always avoided C++ for this reason.

When I made the move to C++, it was very painful to me. In C, I understood every aspect of the language, and going to C++ if felt like 'magic' happening all the time, and trying to understand every single aspect of the language was daunting. Every weird error was another tiring expedition into the language's core, the what and why. Fun is the last word I'd use to describe it, and I always ended up limiting myself to a very narrow subset of C++ because of this. At a certain point however you will be confronted with hairy ugly details of the language. Telling me that 'protected abstract virtual base pure virtual private destructor' is perfectly clear is living in your own small little world.

I enjoy coding in C, it feels like I'm in control, although you really have to do everything yourself, so it's a bit tedious. But C++? No, I absolutely don't enjoy 10-page error messages involving templates that have absolutely nothing to do with the actual error (although you have to give clang some credit here for providing a lot more helpful and compact error messages). It feels like you spend a lot of the time fighting the language and the compiler. Figuring out what a compiler error message exactly means can take a lot of time. And don't say this is the compiler's problem, it's the overly complicated language problem, parsing C++ is an absolute hell - which is the root of those amazingly bad error messages.

I said C++ goodbye about a year ago, and never looked back. My pretty recent discovery of golang was a breath of fresh air. Yes it's not suitable for embedded systems, yes it produces gigantic binaries due to debug symbols always being included and full static compilation (which also has advantages), yes there are no generics (...). It's not perfect, but the language is simple, using it is plain fun, you get a big standard library that even includes a real-world hardened web-server (Google uses it for it's download servers), and there is an amazing amount of 3rd party libraries available for such a young language. It feels a bit like a mix between a scripting and a compiled language - which is nice.

In fact I find the premise of all the Go/Rust/D advocates a bit strange. It makes sense to learn a tool that does something you can't do with your existing ones, but learning 5 tools that are mostly the same is a waste of time unless one is not into collecting tools as a hobby.

If none of these things matter to you, then they do seem similar. But if they do matter, then the difference is much larger.

I consider myself more of a PLT enthusiast than a language advocate. Is there anything about my summation that's incorrect?

And how are Rust and Go "mostly the same"?

I can understand that but keep in mind that C++11 is a completely different language to what it is C++98.

There is a lot of good stuff in the new versions of C++, but the language really could've used a bifurcation years ago.

That said, it's still the best tool in the toolbox for certain problems.

It is still the dominant language for large-scale low-level systems. Critical software driving submarines, power plants, financial exchanges and medical devices is likely written in C++. The code on most of SpaceX's spacecrafts is in C++. Most of Google's infrastructure is written in C++.

With the constant increase of low powered computing devices we are likely to see that "niche" increase.

I think it is rather embarrassing that most code written in modern languages performs worse on today's computers than native code running on 1980s machines.

Performance is what makes computing magical.

"In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering" - Donald Knuth

Sadly, people only cite his other quote about premature optimization being evil, leading to a generation of computer programs written with no consideration of speed and user experience.

In established engineering disciplines, specification is a relatively small part of the work. In software, specification is everything (compilers and interpreters do the heavy duty for you). In established engineering discipline, a 12% improvement in a meaningful dimension (such as construction costs, or interior volume, or…) is easily worth doubling the specification effort. In software, a 12% cut in specification effort is easily worth a 50% worsening of another dimension, such as runtime speed or compilation speed (though of course we must not overdo it http://xkcd.com/303/ ).

Computing is a new enough field that so far that hasn't been the case, but I think with the increase of media processing and large scale data processing, a 10000 machine computer will be the new norm. And just like most other fields of engineering, optimization will be a major concern, if not the primary concern.

http://www.cs.berkeley.edu/~rxin/db-papers/WarehouseScaleCom...

You don't get to just copy a bridge. You have to build another. With software, it is harder to justify building something anew, even if it's a bit different: you could re-purpose the old thing at very little cost (provided the old thing was well written and close to your mark to begin with, which is often not the case…).

Then there's the systematic automation of everything we understand sufficiently deeply. Garbage collection. Compiler optimizations. Libraries, some of which are freakishly fast. Databases.

When faced with a new project, you will increasingly not care about performance, because you will just reuse the incredibly fast infrastructure the system folks wrote for you. Don't get me wrong, performance is likely to become more and more important over time (as you said). It will just take less and less programming effort, as everything will increasingly be put in common —well, as long as we have the internet and Free Software.

More and more, the path to freakishly good performance will be simple, elegant, and obvious code. Algorithms will still matter, but you will hide most of them behind libraries. And you certainly won't do micro-optimizations.

If the compiler is not enough, you can have a team rewrite your hot spots using computer assisted semantic preserving transformations, in a tiny fraction of the effort it took you to write elegant code in the first place. Should you need to modify this code, no problem: just re-run the special set of optimization they devised in the first place. Worst case, the compiler just tells you it can no longer run the specialized optimization on your new code, leaving you with slow code until the optimization team amends its optimization.

Less low-level code will be written each year than high-level code, but it'll still be tremendously important. And as machines change, the underlying libraries will keep changing.

On the one hand, we have required effort. On the other hand, we have impact. To take an extreme example, Web browsers are a tiny niche in terms of development effort. Their impact however is something else entirely.

This is what I predict with low-level stuff. It will grow in terms of impact, but shrink in terms of development effort (at least in relative terms).

> as machines change, the underlying libraries will keep changing.

Increasingly, no they won't. What will change will be the optimization technique that we will need to operate on otherwise clean, elegant, obvious, and slow code.

Take a C library for instance. If it is written in a portable fashion, you only need to write a new C back-end to port that library to another machine. The same goes for semi-manually optimized code. You don't need to change the specification (I mean, the source code) to port the thing to another platform. You only need to change the optimization strategy. It's still an effort, but that's much less effort than a complete rewrite.

He didn't say it wasn't the least dominant. He asked why it was to be considered the best. Dominance is a thing of legacy and you have to take into account a bunch of reasons that have nothing to do with how good a language is to assess why that's so.

Being the best tool is something completely different. I think the commenter has a good point and I think it's clear that a lot of the areas C++ has been used for have been taken over by better languages that offer more without conceding much. In that regard, he is spot on in saying that C++'s niche is indeed shrinking.

C++, like most other languages, is the best tool for some problems and areas, but those are growing smaller and smaller as we identify exactly what we need and create new languages to escape the rest of C++.

Ok, let's play ball.

> After the Cray-1, the Cray Corporation developed another giant named Cray-2. It remained the world’s fastest Supercomputer between the years 1985 to 1989, capable of performing 1.9 gigaflops. ( Source: http://infotology.blogspot.be/2012/04/super-computer-timelin... )

So that's tha fastest of the fast in the '80's. According to Intel, a i7-3770k consumer CPU gets 112 gflops and a Q6600 quad core, which was released in Q1 2007, has 38.40 GFlops. That's a factor 58+ faster on the i7, or a factor 20 for the Q6600.

Now let's take the Q6600 to make it easy to compare languages in a very bad way: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...

I picked the bench config x86 quad core because this had the highest peak. Also, if you take these languages, which are more commonly used: * C#/Mono: Worst 9x, median 2x * Go: Worst 7x, median 3x * Haskell: Worst 3x, median 2x * Java: Worst 3x, median 2x * PHP: Worst 109x, median 36x * Python 3: Worst 129x, median 37x * Ruby: Worst 239x, median 53x * JRuby: Worst 115x, median 34x

But keep in mind that: * Current CPU integer performance, cache speeds, memory bandwidth and general i/o would completely destroy the Cray-2 * GFlops are a real bad indicator of how fast a computer is. Current computers are even faster. Current GPU's are floating point optimized and run circles around any general purpose CPU when it comes to GFlops. * These are CPU-bound artificial language comparison benchmarks. * Native code means nothing. Bad slow code will always be slow, whatever language you use. Some of the languages included do compile to 'native code' (Go and Haskell), and a lot of the interpreted/byte code compiled languages use a JIT to generate 'native code' too. * We don't take into account the Cray-2's bottlenecks (mainly I/O) * All GFlop numbers are according to the manufacturer. * Most applications hit i/o limits before hitting CPU limits (yes there are exceptions) * this is comparing with the fastest of the fast you could get at the end of the '80s

So in worst theoretical cases, sure. In the real world? Not even close.

A few weeks ago I found out that the B-2 Spirit now flys on olde C.

http://en.wikipedia.org/wiki/Northrop_Grumman_B-2_Spirit#Fur...

> I think it is rather embarrassing that most code written in modern languages performs worse on today's computers than native code running on 1980s machines.

Are there any sources to support this statement, or are you drawing on personal experience?

I don't consider an improvement obtained switching from/avoiding a high level language that allows me useful abstractions and to avoid bookkeeping, to C++, an easy thing.

Yes, if the thing is just -slow-, optimize it. But never start out "We can't have this thing be slow; let's write it in C++!" unless you already have some metrics showing that it's -too- slow in a safer language.

There are a lot of great libraries for Python, and it's much nicer and more productive. I use it whenever possible, esp. for making graphics, or when I can use optimized stuff like in numpy. However, most of the programs I write are of the type "loop over 10 million entries, perform a simple calculation, return a number". These are mostly IO bound, and one would think that this is a case where you could use a dynamic or interpreted language. But whenever I tried, the overhead for the large loop and the variable access in tight loops was too high, and the problem became CPU bound. So, in my experience, it has to be a compiled language (or at least something more performant then Python).

I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community.

The ideal language for me would be "C+". A C++ lite, where you would ban most of the complications. You would still be able to write C++ libraries, but then use them from simple C+. A C+ user, as opposed to a library writer, would not have to know about the "safe bool idiom", traits, private destructors, default methods (which are utter maddness in C++11) and template metaprogramming.

I'd then augment this simplified C+ with a powerful static invariant checker. You could say something like "guarantee x < 10; x = f()" and it could complain "you demanded x be < 10, but f() only guarantees x < 100".

The esoteric, and what you need to do what you said, are nearly entirely partitioned from each other. Reading in a list of things, running some code over it, and spewing the results out is not that hard and will not involve anything you can't understand.

That said, even after some relatively extensive use of Haskell I still have poor intuition about how well it performs on such tasks... no, not because of "laziness", but because "naively" written Haskell still involves things getting boxed and other such performance killers that can take you halfway back to Python. I can say writing Haskell to do your described tasks isn't hard... I have a harder time promising you can write performant Haskell just by doing the obvious things. There's some promising work on doing fast numerical calculations, but it still seems like it's very easy to be doing something very fast, then change a bit of code, which silently breaks optimizations and suddenly it's slow for no obvious reason. (Note this is NOT unique to Haskell... all compiler optimizations can have this problem. It's just particularly acute in Haskell, but I've encountered it elsewhere. I've often wished for more transparent optimization feedback in many languages, or the ability to assert that I'm triggering certain optimizations so that if I do break them in the future, I find out at compile time. Alas, I've never seen such a thing.)

Assuming you meant more than having a good FFI…

When I judge the suitability of a language for a task in the abstract, I systematically ignore 2 very important factors: legacy code, and skill availability. I do as if everyone know every language, and we start from a mostly blank slate.

If I didn't ignore those factors, I wouldn't be judging the languages, I would be judging whole ecosystems, introducing a huge status-quo bias in the process.

---

The C+ you look for is probably possible. I bet it could be implemented a la CFront.

I think it's unlikely we'll see anything like Chrome, Ableton Live, or Photoshop written in anything but C++ any time soon.

We are working to change that in Servo :)

There are up and coming languages that can claim to compete in that area, but they're still rather immature and/or lack developer support.

So, which specific problems requires you to both optimize the hell out of your CPU and memory, and mostly work at a higher level of abstraction than C?

I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required?

I'll go even further: there has been a number of C pre-processors spouting up recently. One of them does Lisp-like macros. Another does lambdas. Yet another might address templates. I predict a modern version of "C with classes", which learned from the mistakes of the past (like trying to be compatible at the syntax level).

At that point, do you think there will be any specific problem where C++ is still the best choice?

My sibling here already mentioned AAA game development. Finance is another area where top performance is often required.

Performance is the requirement. Being able to work at an abstraction level higher than C is highly desirable. C++ gives you both of those.

> I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required?

You get a boundary between the "high level" and "performance oriented" parts of the code that is arbitrary and only exists because the high level language performs poorly. There are definite costs to that approach.

> I'll go even further: there has been a number of C pre-processors spouting up recently.

Cute hacks that are probably not suitable for production use.

Let's be honest here. You're asking for problems that require the use of C++ now. The situation is surely going to be different in, say, five years from now - though I don't think it'll be a "C with classes".

I intend to work an a serious C pre-processor this summer, after I'm finished with my Earley parser. This won't remotely resemble "C with classes". I won't aim for any syntactic compatibility, that was a silly requirement. Heck, I'll probably have Python-like mandatory indentation, reworked operator precedence, an overhauled type syntax, switches that don't fall through… But I will keep semantic compatibility, and a relatively obvious mapping to underlying C code. Coffe-C, not Clojure-C.

But even that won't satisfy me. Eventually, I want to make a source-to-source transformation framework that can turn any language into any other. With that, languages become less of a programming interface, and more of an implementation concern.

Beware. That's a pretty common programmer tarpit. I've witnessed two take this on myself. If you never hear about it online, it's because it makes "general puprose visual programming language" look easy; people at least get to the "show something off" stage with that.

It may help to observe that we technically already have an intermediate language that works with all languages, which we call machine language. If it sounds infeasible to read all machine language and convert between various programming representations especially in light of things like VMs and such... well... yeah. That's a fairly direct and accurate reflection of the difficulty in question.

In some sense, this is the absolute purest "inner platform effect" project you could ever hope to undertake. http://en.wikipedia.org/wiki/Inner-platform_effect

C++ is everywhere, from embedded to application software to games to the server side (Google has a gigantic C++ codebase).

I worked on a camera that had its logic written in C++ and it wasn't some unusual thing.

(Of course, I don't take legacy code nor talent availability into account. They are crucial in any real-world decision, but they don't influence the virtues of the language itself.)

Yeah, well, that's just, like, your opinion, man.

Seriously though, don't mistake your personal opinion for some objective truth. There are plenty of programmers out there who enjoy C++ and don't see it as a Chtuloid horror. What you have isn't strong evidence of anything, really.

> (Of course, I don't take legacy code nor talent availability into account. They are crucial in any real-world decision, but they don't influence the virtues of the language itself.)

And there are even more "external" factors to consider, but if you allow yourself to cherry-pick criteria then you can make any language be the optimal choice. Languages don't exist in a void.

My opinions have different strengths. This one has accumulated enough evidence that I no longer consider the possibility of its falsehood. C++ sucks, and that's the end of it. I know of the gazillion eminently reasonable reasons why C++ is what it is, but it still sucks. I know that if Stroustrup made cleaner choices for the language, it wouldn't be so popular, but it still sucks. I know that a better language that nobody use is… well… useless, but C++ still sucks. In my opinion, C++ is one of our greatest shame as a community.

> If you allow yourself to cherry-pick criteria then you can make any language be the optimal choice.

I don't cherry pick. I'm just comparing languages. Not external tools. Not backward compatibility. Not programmer availability. Just languages. The other criteria are short term considerations, and greatly increase status-quo bias. They're only interesting when I must do a small project now, with whoever happen to work with me at the moment.

For bigger projects however, the language is increasingly important. The bigger the project, the more reasonable it is to switch to use a better language, instead of a better known language.

FWIW, I don't think Jane Street is a competitor in the "ultra HFT" space where every nanosecond counts. AFAIK they are more of a statistical and quantitative trading group, so they may have less need for things like talking directly to hardware, keeping tight control over memory layout, deterministic latency w/o GC pauses, etc.

Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina.

You will note that C++ made that sort of ugly compromises from the start. Keeping a C-like syntax really wasn't necessary. (Keeping a C-like semantics, that's a different story.)

I think you may be confusing is with ought here. Everybody sane knows C++ has flaws; I think Meyers even feels this way in his presentation. C++ is popular because it evolved and thus contains a lot of compromises. To draw an analogy, the Mormon Church is immensely popular in the US for similar reason--they basically said, "Hey the New and Old Testaments you spent your formative years learning are all good, but we've got some swell new stuff here too!" I'm sure Zen Buddhism is more theologically pure, but people like what's familiar to them.

Programming languages are a network effect problem first and foremost. Just like it's hard to unseat Craigslist despite its crappy UI, it's difficult to get users for a new language that may be only marginally better in terms of features, productivity, safety or convenience. Even if it's a significant improvement existing code bases, library availability, programmer availability with domain knowledge and so on matter much more for serious projects. There's a reason why Facebook took the time to write a PHP VM instead of rewriting their code.

If only reality wasn't like this. Yes, network effects are ridiculously important. And so is status-quo bias in general. I know C++ wouldn't be nearly as popular if it adopted a different syntax. I know that the ability to compile most existing C code out of the box was a big help in the adoption of the language, even though it technically doesn't matter. This is why I said erlier¹ that C++ is one of the greatest shame of our community. Stroustrup was well aware of our insanities, and he exploited them on purpose, supposedly for our own good. We as a community were simply incapable of accepting anything better. It would have been too different.

[1]: https://news.ycombinator.com/item?id=7938469

> But isn't that because C++ itself evolved from C?

It didn't. C++ did not evolve from C, it was implemented on top of C. Stroustrup didn't started by modifying the front-end of GCC, he started by writing CFront. From there, it would have been real easy to fix some of the most glaring flaws of C: switches that fall through, overly general (and verbose) for loops, the insane syntax of type declarations (ML existed at the time, and could have been an inspiration), the priority of the operators (15 levels are too much, some priorities are backwards), and maybe some operators themselves (the star for instance serves two unrelated purposes, which may be confusing). While we're at it, Stroustrup could have thrown the headers away, replacing them with a proper module system. Nothing fancy, just a nice way to package compilation units.

That was the "fixing C" part. These flaws were known at the time, it would have been easy to fix them. (Except maybe the module system. You still want an easy way to talk to existing C code.)

Then we can move on to building C++: a language with a stellar C FFI, semantics that are identical to C (except for advanced syntax sugar such as classes), but with a much cleaner, easier, and more flexible syntax. This language would have been much better than the current C++ on every possible measure, except one.

Adoption.

It seems we just can't change our syntax. No, scrap that, we just can't change, period. People love "change", but they hate change. There are few circumstances where people are willing to accept change (like this anecdote about introducing OpenOffice as "the new version of Word"). One of C++'s greatest strength (and our community's greatest weakness), was it's apparent similarity with C. It's the same, except with more features! A better syntax for C however, while more useful than a mere C-with-classes², would never have caught on.

[2]: Templates are C++'s killer feature, not classes. (OO as done with C++ and Java classes is mostly a mistake³. But that's another debate.)

[3]: http://loup-vaillant.fr/articles/classes-suck

(I'm not kidding about C's syntax being terrible. Experiments have shown that beginners fare no better with C than they do with a randomly generated syntax. It is that bad.)

So here's my list: A compression library, a crypto library, a numerical library, a video game, high frequency trading system, a high performance application server, a webserver, a database, a storage or caching system, an operating system, device drivers, a web browser, a VM, a programming language.

Granted, many indy games can work by using an embedded interpreter for much of the game logic, but it doesn't take much to run out of computing power at that level and still maintain reasonable (and consistent) frame rates.

I know you could probably do the same with Python but I think small systems would suffer a speed penalty (I even find desktop Python applications slow so I dread to think of GUIs on an ARM written in Python). I reality I have not ever come across a piece of paid software that included a runtime of Python or some scripting language other than Perl, and that clearly wasn't for a GUI app.

What else would you write for all three platforms in? Java? I am curious.

(I suppose if you are targeting one platform only, then it might make sense to write in languages typically tied to that platform, eg. Obj-C / Swift / VB / C# (as is vastly popular in Windows land)).

The paper states that C++ must have done something right, as it is still consistently popular. If ms didn't go all in with it though, I think it would be a footnote in history.

I, thankfully, haven't used C++ much in the past few years after using it nearly exclusively for about a decade, but the one thing about working in it that will always stick with me is how virtually every project would eventually have like 8 different string classes contained within it for much the same reason (different libraries and/or OS level APIs would use different string classes, often their own), and this is well after std::string/wstring were a thing.

That's the real danger with a sprawling language like C++, IMO. Not that you have to use every bit of it in your own code (in your own code you can get by with a very small subset), but the fact that because there's little true consensus on which bits of it to use it, projects with external dependencies (that are also in C++) generally grow to use not only the entire language and standard library in different places, but also a bunch of badly hacked up reimplementations of the standard library that come along with some of those dependencies.

In various circumstances you may want: string_views, copy_on_write_buffers, small_buffers (for small-string optimization), native arrays of chars, std::arrays of chars, std::vectors of chars, tries, and so on.

In all of the above cases, you should be able to write: auto firstSpace = std::find( begin(myCharContainer), end(myCharContainer), ' '); ...to get an iterator to the first space in your container.

And on top of all that, you could make versions of begin() and end() that return iterators that respect various character encodings.

1) You can create range for loops over containers:

  for (auto x: vec) {
    foo(x);
  }

2. You can create shared pointers using make_shared, but you can't create unique pointers using make_unique. What's worse, if you define your own make_unique function, your code will eventually break because it's already decided that C++14 will have its own make_unique.

I'm sure all of this will get fixed eventually, but frankly I don't have more patience for this. The root cause is that the C++ process is broken and is lead by incompetent clueless people.

2. As you mentioned, make_unique is a part of C++14 (although it will still be missing make_unique<T[]> ). I don't see the big deal is though since libc++, libstdc++, and VS2013 already have a compliant make_unique implementation.

This is not true -- see §20.9.1.4 of the C++14 draft [1]. make_unique is defined for array types with unknown bound (i.e., T[]), but it is deleted for array types of known bound (e.g., T[5]). So to make an array of 100 default-initialized `int`s,

    auto array = std::make_unique<int[]>(100);

For me, I am constrained by the compilers that are used by my employers (VC10) so I can't use half of the new features (although I could use them in Xcode and macro them out I suppose).

1. Type deduction (C++ has it)

2. Lambda functions (C++ has it)

3. Support for OOP (C++ has it)

4. Generics (C++ has it)

5. Static typing (C++ has it)

6. Support for functional-style programming (C++ has it)

7. Support for garbage collection* (C++11 has it)

8. A powerful library of data structures and algorithms (C++ has it, and the library is growing very rapidly as well.)

C++ supports pretty much every feature other high level languages support, but the features are opt-in, that is, if you don't use it, you don't pay for it.

*As far as I know, however, no compilers are currently implementing garbage collection. But the language support is there already.

Lambdas/closures in C++ are a total hack.

I'd say C++ is a mid-level language with lots of emulations of high-level features. The integration of closures into C++ is an example of that. Just by integrating a high-level feature poorly into C++ does not make C++ high-level.

assert(doappend_dwim([]) == ['a']) assert(doappend_dwim() == ['a']) assert(doappend_dwim() == ['a','a'])

The GOTO thing in PHP has almost been a non-issue all around, but highlighted the "don't use it if you don't like it" argument's flaws.

I also find that the ancient developer's design style and implementation left a lot to be desired, and if someone came across that as an introduction to a language, I think they would have hated the language too. That's why we should always write beautiful code and occasionally throw in obscure language features to force them to learn them :-)

Not to say tinkering is bad, its perfectly fine when trying to create the latest viral app or when learning how to do something. When engineering something, discipline is required.

And nothing stops any institution seriously committed to engineering to adopting practices that restrict language use to a subset (mandatory code review, static analysis tools that highlight deviant code and disallow it to be pushed, etc).

    C++ most suited for demanding systems applications. [...] You choose C++ when the situation is already complicated.

You can write useful, efficient software in languages that expose much less complexity to their users.

Re: complexity. Not having to understand C++ most of the time, or subsetting the language to have a manageable code base only works until you run into somebody else's code, or some 3rd party library. It's not a fix, it's a symptom of something broken.

But when you need to be able to precisely measure running torque or torque a fitting to known value, you can't avoid picking up the complexity of a torque wrench.

With that, I get the power without the rabbit hole.

Unless you want a truly simple C template system, in which case aren't the C11 type sensitive macros sufficient?

Hey, that sounds cool. Do you have a link? A quick search doesn't seem to work.

The vtables on the other hand I will steer clear from. Closures are way more useful than class based polymorphism. Combine it with parametric polymorphism (templates), and you won't need to subclass anything ever again —okay, I'm exaggerating a little.

On that topic, it is possible to do cool things with macros with GCC extensions. A simple example of generic macros was discussed about a week ago: https://news.ycombinator.com/item?id=7896280

Also, I'm not sure I get this "type erasure" business. In ML languages, there is no such erasure. I guess you need this erasure because the language doesn't support parametric polymorphism to begin with? I'm thinking about Java, which hacked generics after the fact, and maintained backward compatibility through type erasure.

In C++, there are few type erasures. Generally, when we want a function to receive a closure, we write it like this (minus dark corner I have missed):

  template <typename T, typename E>
  for_each(T functor, vector<E>);

By the way, why do we need std::function at all? Every time I saw it, it was to work around some dark corner of C++ type system or template dark magic.

    class A { void foo(); };
    A a;

    ??? thing = a.foo; // doesn't exist

    &A::foo

    void (*)(A * __this)

    struct mem_fun{ A *a; void(A::*ptr)(); };

    mem_fun fun;
    fun.a = &a;
    fun.ptr = &A::foo;

    void operator()(){ a->*ptr(); }

    ...
    fun()

    std::function<void()> foo = fun; // mem_fun
    std::function<void()> foo2 = global_fun; // simple member pointer

I've used C++ over the years off-and-on (depending on what the clients required). You don't really need to use every 'exotic' feature in order to be productive. If you need something low-level with great compilers and a lot of great lib support, it's actually a nice language. All these new languages are nice, but Go and Rust just chisel off the 'ugly' in favor of some different 'ugly', IMO.

I wonder if it was designed to accommodate the way some real clever boffins think so that they could properly express their thoughts and designs in a language?

http://cpptruths.blogspot.co.uk/2006/08/g-compiler-option-we...

Make sure to get a guided tour. You can read all the stuff on the displays and in books, but you probably won't. So you'd lose all those nice stories about how the German ambassador protested the ship, because the figurines on the front symbolized the Roman emperors, with the Swedish king at the very front. Preposterous! The emperor of the Holy Roman Empire of the German Nation is the rightful successor to the Roman emperors, after all!

Pay attention to the fact that the Swedes weren't as stupid as people tend to assume. "Oh, they couldn't even build a ship that's floating!".

Yeah well, it was a design no-one had attempted before (bigger, three masts, two rows of cannons), the math to calculate the behaviour wasn't available, yet. And best of all -- contemporary analysis shows that they almost made it. Had the ship been just a little bit wider (I don't know, something like 20 centimeters or so?), it would have been fine.

Be amazed how the Swedes never just found a scapegoat to punish for the loss of their flagship.

Or just admire the architecture of the museum.

Whenever I'm in Stockholm I go there. It's inevitably a high point of my visits.

On the over-arming of ships going spectacularly wrong, see also the Mary Rose[1].

[1] http://en.wikipedia.org/wiki/Mary_Rose

The natural language example of course being metaphor and allusion, I am thinking of practices such as indenting glVertex calls inside a glBegin/glEnd block, or overloading () on an object to convey the idea that "you should think of this as something like a function" when it is really not on a technical level.

Most such people are probably in the same position that I am in, and this is that they're using C++ primarily because they're involved in projects with a C++ legacy codebase. Language choice really isn't something that's up to individual developers.

But for personal projects, I've pretty much abandoned C++, other than when I need something to bootstrap on platforms that I can't make a whole lot of assumptions on, or when I have to operate close to the metal and C for some reason or another doesn't fit the bill.

The thing is that I don't really have a lot of beef with the language features of C++ (the way they're used in some libraries is a different issue). The features it has are generally there for a reason, and have good rationales. And C++ does pretty well in its chosen domain (system programming). It's not perfect (what programming language is?), but hardly terminally flawed, either.

But C++ simply doesn't meet my needs. It has a very strong bias for optimizing CPU cycles, even at the cost of developer cycles, but I'm far more likely to be short on the latter than the former. Those extra few percent of speed that I might gain (or might not -- some C++ features are not all that efficient, after all) are rarely worth adding even a few hours of development time.

That's such an overwhelmingly good reason to express yourself in English, instead of Esperanto, that you really don't need to postulate any additional reasons.

Most things like programming language choice follow heavy-tailed distributions, which means that there are a few that are overwhelmingly popular, as well as many that are extremely unpopular. The reasons that C++ turned out to be overwhelmingly popular may be mainly historical.

You could probably also blame popularity for making C++ so ornate. It jumped on every language trend over the years. Fortran didn't, but if Fortran had been popular...

The recent updates - C++11, C++14 and the drafts for C++17 are also very welcome.

When you need performant, deterministic, portable and testable code, you go for C++.

* only pay for what you use

* memory safety

* testability

* portability

(They even got a standard testing module.)

EDIT: How do you make lists with Hacker News markup?

Currently Rust doesn't outperform C++ partly because LLVM is optimized for the C subset (can't take advantage of extra aliasing/immutability information Rust has), but given that Apple is now betting on (quite similar) Swift I expect LLVM to rapidly improve in this area.

I should mention that that's different than 'who cares about performance, let's toss this in.' Performance aspects are absolutely taken into account when changing the language. But that's different than the implementation itself.

You just made one.

http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/

I guess C++ will do that to you. :)

Not that this is a bad thing.

I find straightforward, well-written C++ more comprehensible than Java and even Python (only due to Python's dynamic typing).

Of course, the definition behind straightforward, well-written C++ is very subjective.

  auto y = std::move(x);

  auto* x = new Foo();

  auto y = std::move(x);

  foo (A*x);

Here you are just moving x to y. What is the type of y? the same type as x, which supposedly didn't cause you heartache throughout the rest of the function.

Stroustrup gave an interesting talk this year about how, everytime he introduced a new feature, people complained that it was not clear and asked for very verbose syntax. Instead of foo<T>, we get template<typename T> foo<T>(T, well, you get the idea. Now everyone is familar with templates and loath the verboseness.

Back to auto, it allows for 'generic' programming. Do you object to templated functions?

  template<class T>
  T add (T a, T b)
  {
     return a + b;
  }

   auto add (auto a, auto b)
   {
      return a + b;
   }

   auto x = a + b;

IMO you should still use auto there and use a static_cast<int16_t> on the RHS to make it clear to the reader that you're deliberately converting it.

foo(A * x) doesn't pose similar problem. On the other hand, if I write

    auto bar = foo(A*x);

I wrung my hands when I started using 'auto' but none of the worries came to pass.

But yes, if the code is unreadable without a type, add a type. No biggie, and no one is suggesting inflexible application of rules (always use 'auto' if it is possible). The same way when I might call

   foo(boo(x));

   auto robot_velocity   = boo(x);
   auto robot_covariance = foo(robot_velocity);

   robot::vector<float> robot_velocity         = boo(x);
   robot::matrix<float,float> robot_covariance = foo(robot_velocity);

Interestingly, no one worries about typedef. typedefs wrapped around intricate collections (map of lists of dictionary of arrays) can effectively obscure what the underlying types are just as much as auto. But again, mouse hover, CTRL+I, or whatever your IDE supplies pretty much makes that a non-issue as well.

edit: the problem you are describing is due to too big a function, not 'auto'.

This is gun control applied to computer languages.

The solution is not to ban a useful feature that would ordinarily aid the understandability of code, the solution is to not abuse such features to write gibberish.

People can write spaghetti code with any syntax you provide them, even Python.

There should be no such thing as deep in a function, or at least not as deep as you mean (i.e. so deep that you can't figure out what y is): that would in all likelyhood mean your function is too long, has too much responsabilities. Good functions are short and composed of other short functions, they should be short enough so that you can read them through without ever having to wonder 'wtf is this?' I know this might sound like textbook stuff without practical use but it's simply the truth, as I learned through the years. In those years my functions only became shorter, and hence better named, and more reusable, and all code simpler to read. So auto was a godsend that didn't hurt once.

Personally, I avoided type inference in C# for a long time. But I never ran into a bug caused by type inference. While C#'s (and C++'s) type system isn't as advanced as Haskell's, if you screw up the types you generally get a compiler error. If "auto y = std::move(x)" compiles, then why do you care what type y is? You know it's the same type as x, and you can do anything with y that you could have done with x.

There's really nothing to fear.

    vector<T> foo = ...
    auto tmp = foo[0];
    foo[0] = foo[1];
    foo[1] = tmp;

So yes, be afraid.

An updated version of ScopeGuard doesn't have this problem ( https://github.com/facebook/folly/blob/master/folly/ScopeGua... ).

So, yes, I'll concede that code that expects you to cast some kind of proxy type to a different type (e.g., the vector<bool> example, or the original ScopeGuard, or perhaps valarray) isn't ready for type inference. But that kind of code is pretty rare, so the list of exceptions to the rule should be short.

Besides, if you want to swap two elements, use std::swap.

I'll stop it now.

And even if we make it not-generic, and add some C++11:

    std::vector<bool> foo = ...;
    auto tmp = std::move(foo[0]);
    foo[0] = std::move(foo[1]);
    foo[1] = std::move(tmp);
 

(It works if you use std::swap, I think because whatever type tmp resolves to happens to overload std::swap to do the right thing.)

So why is vector<bool> the "real problem?" It's because its operator[] doesn't return a bool&, but instead some type "convertible to bool," that may do lots of other stuff too. But the standard is chock-full of language like that. For example, with iterators: `str.begin() != str.end()` Is that a bool? `str.begin()[2]`. Is that a char? The standard doesn't require either. Care to roll the dice by assigning one to auto?

Type inference works well in other languages, but it is more dangerous in C++ due to the risk of implicit conversions. C++ does so much stuff for you under the hood that it can be quite hard to figure out what is really going on, and auto only makes that problem worse. Use with caution.

The point wasn't that your swap implementation was bad, but that you would never write swap yourself. It was made even worse for generic code because types are expected to be able to provide their own swap implementation.

> So why is vector<bool> the "real problem?" It's because its operator[] doesn't return a bool&, but instead some type "convertible to bool," that may do lots of other stuff too. But the standard is chock-full of language like that. For example, with iterators: `str.begin() != str.end()` Is that a bool? `str.begin()[2]`. Is that a char? The standard doesn't require either. Care to roll the dice by assigning one to auto?

But the standard says that sequence containers with operator [] must return a reference, not a type convertible to T. If you wrote your swap implementation against the requirements of a container, it is fine, the problem is vector<bool> is not a container. As for other parts of the standard that do permit the type to only be [contextually] convertible to some type T, there is no rolling of the dice, your code is correct or it is not.

I agree "auto y = std::move(x)" is (likely) poor coding practice. I only use "auto" basically as a shorthand (e.g. instead of writing "hand_crampingly_long_container_iterator_type v = std::fn(c.begin(), ....)).

I have mixed feelings about "polluting" the namespace with "useless" typedefs and similar aliases versus using "auto". The former leads to very explicit code, but lots of extra "overhead." On the other hand, "auto" is much more powerful than a convenient in-place alias as I've described, and I've rarely found myself in the position of looking at code and having to truly ponder over the type of an "auto" variable. On the other other hand, seeing a lot of either may indicate something else about the code and whether it ought to have a design review. It's (somewhat) subjective.

Unfortunately the slides are not online. But his presentation starts with a case of why 'auto' should often be preferred to explicit type declarations.

    auto* x = new Foo();

As for something like

    auto x = std::move(y);

It's an odd mental leap for this old C hack, but it works quite well when you get into it. Bonus - no 'free' or 'delete' necessary.

    auto x = std::make_unique<Foo>();

    auto it = std::find(vec.begin(), vec.end(), value);

  auto foo = *it;

What if "it" were originally an unsigned int* but a refactoring changed that to a long*? Would you prefer the programmer hunt down all cases where "it" is dereferenced to change the type of the result, or would you prefer the programmer use "auto" to begin with?

In a template, you're somewhat better off using Container::value_type. Though not by much.

The unsigned int* -> long* example is a good point. But auto doesn't fully solve that problem - consider something like iter = x or some_func(iter). The auto also makes it more work to figure out what the underlying type is. You're probably better off using a typedef.

  auto gps_position = *saved_position;

Balance, proportion, judgment, and code reviews are how you get great code, not 'never' and 'always' rules (which your comment makes clear you agree with).

That said, presumably one solution for such an issue is that have IDEs that can easily tell you what the type of an auto variable is.

http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/

I think the STL may have been the worst thing to have happened to C++. It could have been so much nicer if something like Qt (the core part) was adopted instead.

If Qt is anything like wxWidgets, wxWidgets reuses the STL for its container types, basically providing a thin wrapper over the STL (or it can do with a build switch).

I myself find the STL very useful, so I am genuinely interested in which bits of the STL you wish were more Qt-like? Do you mean the GUI bits of it or something?

Qt doesn't reuse the STL container types, it provides its own - which I find much more pleasant to work with than their STL counterparts. The STL puts a lot of effort into providing types of flexibility that are irrelevant or useless to me (e.g. allocators) and doesn't provide lots of simple things that I need every day (e.g. an indexOf method for std::vector, a contains method for std::set, or a toUpper/toLower method for std::string).

Regarding iOS and Android, the attempts at getting C++ on them (particularly Android) are brave but I think for normal apps (not OpenGL or games), developers are probably better using Java. Like you, I too am writing for the Big 3 normal desktop OSes, with sporadic Android development and iOS tinkerings, necessitating learning new languages.

I think opinions on that greatly vary. I for one find a majority of what is in STL very well-designed and very usable.

But if you'll indulge me for a moment, consider how you'd convert a string to uppercase using the STL vs using Qt. The STL code (taken from http://en.cppreference.com/w/cpp/algorithm/transform) looks like this:

   std::string tmp = s;
   std::transform(tmp.begin(), tmp.end(), tmp.begin(), std::ptr_fun<int, int>(std::toupper));
   return tmp;

The equivalent Qt code looks like:

   return s.toUpper();

By the way if there's a simpler way to do that using the STL, I'd love to hear about it.

    transform(begin(tmp), end(tmp), begin(tmp), [] (char c) { return toupper(c); });

It is also trivial to write a mylib::transform_in_place() that cuts down on the noise with a one-line function.

And yes it's trivial to wrap this in a function, but in my opinion it really shouldn't be necessary. It's such a simple and common-place operation, why isn't it in the standard library?

just a sidenote - this is exactly the opposite of the way of thinking the STL promotes: in STL terms, you do want a generic operation on an arbitrary collection of anything that happens be compatible with toupper. Shouldn't even be a char, let the compiler figure that out. And as it turns out, std::string happens to fit in nicely.

Edit: I hope that doesn't sound too combative - I'm just trying to explain myself, not saying that you're wrong.

from this single example I could say 'STL isn't bloated and contains just the things necessary while leaving plenty of room for extending. That is just the way it was designed' (And extending it is something I do regularly, resulting in a header-only library with tons of small helper functions containing something like noted in the other comments 'transform_inplace' and 'to_upper' which is implemented using the former. Also the resusability of most of these shouldn't be underestimated.) - but for this case I sort of agree that toUpper could have been a member of string becasue it's pretty basic and that if you work with strings regularly QString is nicer from the start as you don't need extra functions. But of course that opens the road to others saying that if toUpper is there, then why shouldn't x and y and z be there.. Never-ending :P. Which is also probably why the STL is the way it is.

* non templated tuples instead of struct: for example, 2 struct types are the same if the data types they hold is the same. Not sure if it's possible for statically typed language.

* tighter STL container integration with the core language syntax

* some way to do modules

* some new thing to make compiling much faster, so to avoid relying on precompiled headers. go and rust are so much faster for this, C++ is not. I still wonder if there could be some gcc or clang extension for this, it would be really appreciated. C++ is awesone to work with, but language implementations suffers from those little details.

C++ has std::tuple, but most people (myself included) find nominal typing easier to understand. I Would only use std::tuple in situations where I needed to store a values of the types of a variadic argument pack.

> * tighter STL container integration with the core language syntax

C++ actually does pretty well here, it has operator overloading as well as std::initializer_list.

> * some way to do modules

Hopefully a good modules proposal makes it for C++17

> * some new thing to make compiling much faster, so to avoid relying on precompiled headers. go and rust are so much faster for this, C++ is not. I still wonder if there could be some gcc or clang extension for this, it would be really appreciated. C++ is awesone to work with, but language implementations suffers from those little details.

Modules would help with compile speed. IMO, Go doesn't offer very many abstractions to the programmer that the compiler must eliminate so its easier to compile quickly. My 1 day experience with Rust was that it actually compiled quite slowly, do you have any personal experience with the language that you found it compiled quickly ?

  (42, "foo", fun x -> x+3)

  int * string * (int -> int)

  type 'a option = Some of 'a
                 | None

  type 'a list = Cons of 'a * 'a list
               | Empty

Integrating the STL at a syntax level gives a special status to the standard library, preventing users from writing effective replacements or analogies. Also, C++ has precious little orthogonality left, let's not destroy it.

---

What kind of modules are you talking about? C++ has compilation units, classes, and namespaces. What capability do you want that they don't already provide?

---

Good luck on the fast compilation front. That one will likely require removing things from the language, or making some major compatibility-breaking changes in the syntax (to make it easier and faster to parse), and possibly a rework of the template system. No. Way.

See http://clang.llvm.org/docs/Modules.html and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n207....