Hacker News Reader

Comment by nly | Hacker News Reader

Looks like C++17, like C++14, is just going to be a spit shine over C++11.

Concepts, modules and coroutines were perhaps the three most anticipated features, and they failed to deliver all three. No STL2 either. Woeful. The field is now wide open for the next 5 years for Rust to come along and eat C++s lunch.

The whole TS/std::experimental idea is just a folly. As a C++ programmer I just don't care if a library is available via a TS vs Boost. There's literally zero advantage to a TS. None. I'd rather stick with Boost, because then at least I only have one implementation to test against, instead of three, each with their own bugs, omissions and performance characteristics.

I've even taken to using boost::container::string where I can, instead of std::string, because the libc++ and stdlibc++ implementations have different performance characteristics.

View on HN

> Concepts, modules and coroutines were perhaps the three most anticipated features

Were they? They're great and all but from a practical standpoint I'm most excited about networking being baked in. I do almost nothing nowadays that doesn't require some form of networking. Now I can do it without bringing in any extra dependencies beyond the STL? And it's portable? Yes please!

I'm not a huge C++ developer. Maybe if I was other things would be more important to me. But adding in networking makes me want to use the language again.

Networking is a very particular set of features that you only need if you are, well, doing something with the network. I'm not and probably never will, for example. But concepts and modules (and perhaps coroutines) were general features that would have potentially benefitted every single problem domain, since they are fundamental to how you use the language, not what you are trying to do with it.

If you are talking about networking TS based on boost:asio, it is much more than just networking. It is a full fledged multi threading library.

Fair enough. But honestly the lack of modules never kept me from doing C++. It was more the lack of a modern standard library. Pretty much every modern language has a way of conducting networking with their standard library.

Though you have a great point. Really miss using C++ and while it still has tons of awesome ideas / stuff parts of it are just really far behind many other languages. I'd love to see modules come in and someone create a good package manager that uses them.

Doing networking in the standard library without introducing a proper async framework is just more madness. Polishing off promises and futures, and getting coroutines nailed down, would have made introducing an intuitive network library a doddle.

Instead we'll get something carved out of ASIO, which is a complete mess full of gross unintuitive APIs and callbacks.

What's wrong with ASIO interface? My only issue with it is that once a socket is bound to an io_service it can't be easily rebound to another one.

For many applications where C++ is used, promises and futures introduce unnecessary overhead. On the other hand an ASIO-like interface works just fine.

Additionally, ASIO, and by extension the network proposal, have transparent opt-in support for futures via a special callback type.

Example terrible API: You have to create a socket for a new connection before calling async_accept. Try using this with coroutines.

> opt-in support for futures via a special callback type.

Which is ugly. The coroutines opt-in as well. Coroutines actually have the potential to be faster than callbacks.

At the places that I have worked the compile (and link time, even with using something like Incredibuild) time is a huge factor. Being able to have modules would have improved this significantly.

Coroutines would also have been useful in many circumstances.

Well, there is progress on all features, yet nothing is ready to go into C++17. So either we get no new standard at all, or we get a Standard without the large features.

Also C++14 was a step forward, generic lambdas are a step forward (boost::hana is based on this, and brings though compile times down), I expect similar language features in C++17, that ease the programming and will bring new innovations to C++.

Your boost argument is only valid for library features. Modules or concepts can never be a part of boost in the way they are in the TS.

> So either we get no new standard at all, or we get a Standard without the large features.

No new standard then. The C++ compilers, standard libraries and the ecosystem have barely caught up with C++11, and C++ 17 was now on the horizon. If it doesn't bring much benefit, then it really cannot justify the compatibility nightmares. I for one will skip it.

> Your boost argument is only valid for library features.

That is exactly the point. Library features are not exciting as they can be implemented just fine and better by third parties. Therefore a C++ standard with only library features are hardly useful at all.

> The C++ compilers, standard libraries and the ecosystem have barely caught up with C++11

That's not really true. Both GCC and Clang have reached C++11 and C++14 feature-complete status very quickly.

The latest versions, yes. But how many production system use the latest compilers?

For me concepts are a joke. They have been in development, like, forever (heck, even perl6 project got started and was released in the meantime!), they are hugely polarizing for the committee and the supposed benefits are, well, lofty. In the meantime everybody just got better at spotting common patterns in template error messages. Is there a point beyond which everybody will essentially give up or is it a point of honor to bring them into the standard?

I agree. In particular, I'm extremely disappointed about their failure to deliver concepts.

The language is just too complicated at this point. Any time you want to add something you need to ensure it plays well with everything else. It is a huge amount of friction.

As is Bjarne.

Keep in mind that the C++ committee is made of up a group of volunteers and is an entirely non-profit organization. Membership participation actually comes at a great personal cost of the individuals. When I see language like "failure to deliver" it makes me wonder if the committee process is being fairly perceived by the larger overall user-base.

As an aside, anyone can join the committee if they really wanted to see a particular language feature see the light of day in a certain way. It's not as hard as you might think. All it takes is a bit of hard work on any sufficiently motivated individual's part.

There's a great discussion of the process here: https://www.youtube.com/watch?v=PqU_ot4BlNQ

I'd say I could do without concepts, modules and coroutines but ranges ! Ranges were so nice and would finally allow for easier stream handling.

Whats holding you back then?

Eric Nieblers Range-v3 library is available:

https://github.com/ericniebler/range-v3/

Its not going to be (much) better in the standard...

Except that it would use real concepts then...

Sure, if you ignore statements (from the author!) like:

> Check out the (woefully incomplete) documentation here.

and

> No promise is made about support or long-term stability. This code will evolve without regard to backwards compatibility.

That's not to say I blame him, but you really shouldn't be recommending range-v3 for general use.

Good realization. Now take it one step forward, and realize that C++11 was just a "spit shine" over C++98 (although spit isn't the bodily fluid I'd use to describe it). It's all part of the marketing machine to sell an ancient programming language riddled with security holes and WTFs. And it's working pretty well, unfortunately... the Donald Trump of programming languages.

Reply on news.ycombinator.com