C++17 and other future highlights of C++
meetingcpp.com
meetingcpp.com
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.
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
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.
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.
That's not really true. Both GCC and Clang have reached C++11 and C++14 feature-complete status very quickly.
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.
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.
Instead we'll get something carved out of ASIO, which is a complete mess full of gross unintuitive APIs and callbacks.
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.
> 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.
Coroutines would also have been useful in many circumstances.
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...
> 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.
---
Library implementors would have to implement it. Most of them are probably unqualified to do it, so they'll probably just grab Boost's implementation. And Boost's implementation would be unreadable to most implementors. Thus everyone would get a slightly subpar implementation, because most numerical researchers are not keeping an eye on Boost and making sure it has the best methods available. The end result is that those in the know will avoid the C++ stdlib, just like Qt did and reimplemented strings and maps.
We've seen this problem before with valarray and with export. There is a problem with standardising something that nobody wants or nobody can implement correctly.
For example, if you want to implement a Student's t-test, you soon will run into the problem that you want to have a Beta function or the gamma function.
One could probably copy-paste a somewhat working version together from search engines, add asserts to prevent me from ever calling them with arguments out of the range where it seems to work, but for most of us, the result likely will be slower and less precise than a version that gcc, clang, or commercial compilers would provide.
And yes, I could probably buy an implementation somewhere, but in the real world, that often isn’t a real option, and even then, I wouldn’t know how well it worked, either.
I've wondered the same thing myself. They're probably easier to standardize since the specification for that behavior is already done by mathematicians. And the implementation is generally re-entrant so the possibility of show-stopper design bugs is minimal.
Getting concepts wrong, in contrast, has a much larger downside.
Not saying special maths should be standardized. Just attempting to describe the phenomenon.
For instance, it is crazy that something as critical and commonplace as "std::iostream" is riddled with error-prone design decisions. The "<<" operator choice is wrong, and it fails basic localization requirements before you even get into its other problems. To this day, I see people who don’t handle stream errors correctly in every case (and who can blame them, when you have stuff like “bad() is actually not the exact opposite of good()”?). Don’t even get me started on the fact that most flags have two different pairs of constants with similar names, used in different contexts, with different values, that will even compile after the wrong one has been chosen (producing who-knows-what behavior?). Or the fact that global stream states can be screwed-with from anywhere, meaning that when a library call returns you can’t be sure that your own "std::cerr" state is “undamaged”? And this is just from streams! The list goes on.
IMO, what's happening with modules is basically the best (realistic) outcome. Up until Jacksonville, we had only a proposal and all the implementors either implementing their proposal, or implementing nothing waiting for a TS. Modules were blocked on the committee. And that's a slow place to be blocked.
Now we've cleared the major hurdles for a modules v1 TS and gotten to the point where implementors are unblocked by the committee and we can start actually building and using it. If the early-adopters want modules from their implementations, they'll actually be able get it, now, finally.
Once implementations start happening, and we gain a bunch of "deployment experience", it'll be a whole lot easier to chart a course through the remaining thorny issues with respect to macros and "middle-up" deployment to existing codebases.
I was hoping for reflection, but it was clear to me a few years ago that there wasn't enough interest or agreement there. But I think a lot of people expected modules and concepts.
In C++11, I think that the most overlooked feature is attributes. Finally, a way of potentially doing AOP without resorting to hacks :-)
I learned C++98 pretty deeply (better than it deserved) but apart from a few things like "hey cool you guys sort of have lambdas now and auto and some new pointer types I'll learn if against my hopes I ever have to do anything important" I haven't really kept up much, but I know there's a lot that has been added. My friend (who just knows a little C++98, his main languages are higher level things for writing automation tools) was talking to me a few weeks ago about finding a bug in his boss's code and having a moment of "Nope, let's wait for him to come back tomorrow" after seeing the totally unfamiliar rvalue reference && in a constructor he tracked down as the source of the bug... If I were to become involved in any C++ project again, if it wasn't strictly maintenance work I'd feel very uncomfortable doing anything without first taking a chunk of time to learn everything new. I feel like that chunk of time would better be spent on Rust, and if I were a manager looking to build something brand new that needed to be low level, I'd also be heavily looking at Rust and hiring people who know it or people who want to learn it, vs. going with C++ and hoping that people that put C++ on their resumes actually understand the modern details on a more than academic level (which would be hard to test for in interviews) and if they don't shelling out the same cost to train them as that of training newcomers to Rust. As for what motivates me out of the office as a true C++ replacement so that companies don't have to train me on their dime, Nim is much more fun.
Can't help but think Jonathan Blow's new language designed for games will blow C++ out of the water, and will probably arrive much sooner than these long drawn-out C++ committee features.
There probably is a workaround for this, as there is a workaround for every other "feature" too, but the more seldom I write C++, the more I realize the language could really use a streamlining. Programming languages are weird, as they seem to develop more, not less, rough patches and glitches as they age.
history.go(-1)I was writing a physics engine at the time, and it was a huge hassle that this wasn't standardized in C++. I used three libraries which each had their own definition of short vectors. Way too much conversion.
Matlab has one notation for arrays and matrices. So all Matlib libraries are compatible at the array and matrix level. This is one reason that much number-crunching is done in Matlab.
Rust already has at least three libraries for short vectors.
An interesting library is Boost::SIMD (!! not part of Boost !!): https://github.com/NumScale/boost.simd