C++17 Is Near, A Look At The New Features

[coder]

If I would add new features to your tools in secret, that would not lower your productivity. You cannot argue that more features inherently lower productivity.

Sorry, but I have to disagree. It adds complexity to the compilers, which results in new bugs and slower improvements elsewhere. Also, when you work in a team or with 3rd party libraries, sometimes people do things that force you to learn a new, dark corner of the language. The idea that "unused complexity is free" is a dangerous fallacy. And I say that as one of the most sophisticated C++ users I personally know. In reality, I'm most likely to be that a-hole who used a template as a parameter to another template (actually, I do that quite rarely, but you get the point).

Not knowing Rust, I'm not against it. I'd sure hope that 30 years and a clean slate would enable a better language than C++. I just hope it was designed in totality, unlike so many recent languages that started out clean & elegant but soon bloat up with awkwardly-added features that were hastily left out of the initial spec.

[pipe13]

coder aliases St. Dogbert

[hansg]

In case you haven't noticed, most comments that mention Rust aren't coming from it's users, but outside observers to the language. In addition, regarding Phoronix, Rust is typically brought up by detractors that are against Rust's adoption. It's rarely ever a genuine comment about rewriting something in Rust. That said, Rust is an open source language and it's adoption is driven by word of mouth. Claiming that you'd rather never see a comment about Rust is simply not a possibility. The more people talk about Rust, the better. If you don't like it, then that's your problem.

I have no idea on which basis you draw that conclusion. People who aren't using rust presumably aren't so interested in it that they want to drag it into every topic. And yes, the comment "this should be done in rust" is about as predictable as the shitstorm that accompanies a new systemd release.

This simply isn't true, and you know it.

You need to look at some benchmarks again. C++ overtook C in terms of raw performance a long time ago.

This is purely trolling. In no way, shape, or form, could a GC language running a VM approach C/Rust.

Actually the trolling happened when Java was introduced, and in the first few years after, when we were told again and again and again that performance was as good as C. It was never actually true, but that didn't stop Java enthousiasts from claiming it anyway - and if someone called them out on it, the 'just over the horizon' magical new compiler would change everything (same as you claimed for rust). Only problem is... it never did.

Fortran produces faster machine code than C because it has no concept of pointer aliasing. That doesn't mean that all implementations written in Fortran will be faster than all implementations than C. How many times must it be brought up that the benchmarks game is not a reliable language comparison tool?

Your frantic handwaving about a purely theoretical advantage does not stack up against actual real measurements.

So you're admitting that you have one week's worth of programming experience.

Insults are a great way to win an argument. Shows you are a deep thinker, with a firm grasp on the subject.

[coder]

Insults are a great way to win an argument. Shows you are a deep thinker, with a firm grasp on the subject.

Okay, so exactly what is your objective, here? Are you trying to resolve the C++ vs. Rust debate in this thread?

Look, good points were made on both sides. Further, I think none of us wants to believe that C++ is the pinnacle of systems programming language design. If Rust makes some advancements in important areas, I view that as largely a good thing. Importantly, I'm not threatened by the specter of its progress.

Truth be told, I feel more threatened by people bloating up and complicating C++ to the point where I can't recommend it, in good conscience. Just look at the size of Stroustrup 4e. If you don't see a problem with that telephone book of a language manual, then I have nothing more to say to you.

And you're welcome... for having your lexical scope returned back to C++ standards.

[mmstick]

Sorry, but I have to disagree. It adds complexity to the compilers, which results in new bugs and slower improvements elsewhere. Also, when you work in a team or with 3rd party libraries, sometimes people do things that force you to learn a new, dark corner of the language. The idea that "unused complexity is free" is a dangerous fallacy. And I say that as one of the most sophisticated C++ users I personally know. In reality, I'm most likely to be that a-hole who used a template as a parameter to another template (actually, I do that quite rarely, but you get the point).

In regards to Rust, this is solved by having multiple compiler IR stages. Rust -> HIR -> MIR -> (LLVM IR | GCC IR | Cretonne IR). Adding a new feature is trivial because it's just parsing the high level syntax and desugaring that for the HIR. By the time the code reaches the MIR, the language has been reduced to a very limited set of keywords, so the only optimization work that needs to be done is here.

Not knowing Rust, I'm not against it. I'd sure hope that 30 years and a clean slate would enable a better language than C++. I just hope it was designed in totality, unlike so many recent languages that started out clean & elegant but soon bloat up with awkwardly-added features that were hastily left out of the initial spec.

The closest thing that Rust has to a spec is the RFC process. One person submits a language proposal, receives a lot of feedback on the proposal, and if a consensus is reached to pursue the proposal, the proposal is rendered in markdown and placed among a list of other proposals waiting to be implemented. This process is an open door process managed on GitHub, so anyone is free to peruse the selection of proposals and comment on them. You won't find any sort of hasty decisions here. However, Rust was already a very strong language when it released the 1.0 version, as it remained in development for a very long period of time (2006-2015). Being implementation-first, it is also free of the issues caused by C++ committees making decisions on paper that later turn out to be terrible in practice.

[hansg]

Okay, so exactly what is your objective, here? Are you trying to resolve the C++ vs. Rust debate in this thread?

I would love to have an interesting discussion about C++17. I don't particularly care for rust (neither in a positive or a negative sense), but I am getting fed up by the relentless advocacy. Then again, it's hard to have an interesting discussion about C++, isn't it? For any feature that gets added, the response is either "what! Only now!? Language X has had that since the seventies!" or "and yet another feature gets added and bloats the language even more. Woe is me, I will never be able to learn all that." Neither is productive or interesting.

Personally, I found C++11 to be a major step forwards. The larger feature set has inspired criticism, but I find that on the whole, code got simpler as a result. I 'lost' around 30,000 lines from a 300,000 line application, thanks to the greater expressiveness offered by C++11 and its more powerful standard library. Stroustrup is telling us C++17 represents an equally large step, but if I look at the feature lists in the new language I don't really see much to get excited about - much of it seems focused on removing small wrinkles, evolution rather than revolution, and on offering facilities I just don't know what to do with. On the other hand, the massively useful modules feature got delayed again.

One criticism I would level at C++ is that it has, perhaps, too much of a focus on language features that are primarily useful for generic library builders. I'm not arguing we don't need that, far from it, but I don't find myself writing lots of generic templates for use in what I would call 'normal production code'. But hey, with just one week of experience, what do I know?

[ldo17]

In my opinion, it is mathematically impossible for a purely text-based (ASCII, UTF-8) language to avoid awkwardly-added (syntactic) features during 30 years of evolution.

ANSI C managed to add function prototypes, and get rid of the old K&R argument-declaration syntax. I would say that was a reduction in awkwardness.

[coder]

Being implementation-first, it is also free of the issues caused by C++ committees making decisions on paper that later turn out to be terrible in practice.

This reminds me too much of Perl, Python, and D. Okay, I have little insight into the design process of Perl and D, but they're both languages which have pretty much one single interpreter/compiler.

For at least some ISO standards, there's a policy that an implementation must exist before it can go into the official standard. I thought that was true for C++, as well. Of course, having an implementation vs. having a community with years of usage experience are two different things.

Anyway, I like most of the additions in C++11, but I feel like they really needed to draw a hard line that any additions or enhancements must make the language: easier to use safely, enhanced portability, or address some major, practical limitation or hurdle involved in using C++03. If they'd done that, I think it would've had more benefit for the long-term health of the language than larding it up with crap like if-init and structured bindings (to pick on the new standard).

Seriously, you can write C++11 that's almost incomprehensible to a knowledgeable C++03 programmer and boost user. That's a problem, IMO.

[coder]

Also, I should add that I think the C++ standard went from moving too slowly (pre-2011), to moving too fast (post-2011). At my job, we're still using the vendor-provided GCC 4.8 series. Yet, there's already an open source library I tried to use which requires some C++14 features not supported by GCC 4.8.

I'm in the same boat with Android NDK, where I now have to switch to clang, because they stopped updating GCC at 4.8. I also get to rebuild a couple dozen libraries we're using, because gnustl has some incompatibilities with clang. While this effort would be justified for a shipping product, it's a major setback for a mere part-time research prototype.

The point being that transitioning real-world software projects takes time, and is a fragile proposition. It can involve multiple platforms, each with their own tools, and sometimes many libraries. So, when the standards committee adds sugary treats that tempt library authors, it can result in all manner of fallout. That's one reason I think each new language feature should have a solid justification. And maybe C++14 should've really been restricted to a "bug-fix" release.

[igouy]

How many times must it be brought up that the benchmarks game is not a reliable language comparison tool?

I guess, until you share with everyone something you would describe as "a reliable language comparison tool".

Meanwhile, the performance section of the Rust FAQ points to…

https://www.rust-lang.org/en-US/faq.html#performance