One problem I have with the advice to use the newest language features in C++ is that it sacrifices one of the biggest advantages to writing code in C++: the ability to compile for multiple platforms. It's extremely unlikely that one has a compiler for every platform that supports all of these features. Additionally, each of these language features adds a small bit of convenience to the developer, while making the compiler substantially more complicated (and hence, more prone to errors).
To summarize the points made in the first 10 slides, which is far as I read (sorry)-
1) Always use auto.
2) Use for-each.
3) Don't use new or delete.
4) Use STL for everything.
5) Use smart pointers.
Do you have war wounds from the C++ ARM or K&R C days?
I have. That was one of the reasons many of us enjoyed using Java.
It was much easier than dealing with all compiler and OS compatibility issues.
The situation with C++14 compatibility is way better than on those days.
I used template heavy C++ back in the late 1990s, rolling container classes implementing smart pointers it was tricky to get good code compatibility across a range of compilers: Edison Design Group, icc, MSVC++, gcc. Ultimately I found myself reassessing the tradeoffs in using C++ for many projects.
Fast forward to 2015 and the situation is much better - even for "soft" embedded scenarios. GCC and clang have good reach and MSVC++ is evolving with the language.
Engineering decisions are often about making tradeoffs and with the state of C++14 and things like C++ Core Guidelines and good support for RVO/move optimisations I find the appeal of C++ has broadened again. And there is good support for modern C++ on many platforms.
Of course there are platforms out there where C++ is still not suitable. For example I'm currently doing a lot of 8086 real mode work, where due to external constraints all the code has to be written in assembler. Neither C or C++ are candidates for me in this work. These platforms will always exist. But many embedded platforms with smart phone level of processing power are solid targets for modern C++.
Is that really one of the biggest advantages to C++? Both of the other languages that you mention, can target a huge amount of platforms. Java, Scheme. In fact, I think that's a feature of very many modern languages, And specifically of C, which may be a much better choice if compatibility is your preference. It seems that the choice to use C++ is not likely motivated primary by platform support for most developers.
C++ is still necessary (evil) in some cases, but as a C++ programmer I have enough and I plan to move to other languages.
Programmers can build very complicated systems using the simplest languages available.
Techniques for eliminating this leaky abstraction are important indeed.
I agree that a function chaining syntax would be preferable. LINQ to Objects in .NET can do something like this because the language(s) support extension methods.
Why criticize the author about a point they went out of their way to tell you was just a stand in for whatever syntax thought made a better choice?
Nothing can salvage C++ at this point.
It needs to be EOLed and put to rest.
Otherwise C++ is going to continue filling the space for large, performance sensitive applications.
Realistically, I don't see C++ going away for a looong time (if ever), simply because of the huge amounts of code written in it. But if one were looking for an alternative that matches C++ both in performance and control over memory layout, Ada is where I would start. It has generics, you can do OOP, it avoids many of the syntactic pitfalls of C++... As a bonus, the language standard and the rationale are available for free.
Concurrency / tasking in Ada is simple and beautiful, however. One of the most compelling features of the language, especially coming from C++.
I guess you could say that is even less reliance on GC than C++ has, with smart pointers being part of the standard.
Even if I'm not using Lisp for the end product, whose SLA may not permit a runtime with garbage collection, I always find it invaluable to define low-level structures with a Lisp whose machine code compiler is available at runtime for experimental interactive development.
A free and open source Lisp that you might enjoy experimenting with is SBCL, available from http://www.sbcl.org.
Load up the REPL, and follow the manual available here http://sbcl.org/manual/index.html#Foreign-Function-Interface.
SBCL also allows you to interactively augment the machine code compiler, install new intrinsics, and disassemble any function interactively.
Even if you never use it for production code directly, it might become an invaluable tool in your low level development process.
Edit(since I can't reply yet to child):
By in-place loading I don't mean placement new(which untyped arena covers). Usually in-place loading means constructing an object(usually just by reinterpret_cast<T*>(data)) over a block of memory read in from disk/network such that all data members "line up" with data as it was serialized.
This also includes the ability to mutate the in-place data but have initialized to some sane values. 99% of the time this is paired with either some sort of preprocessor(usually written in the same compiler as the reader to guarantee data matching).
Quite a few games use this technique to allocate levels/fixed entities such that once you've pulled them disk you just need to do some trivial pointer fixup and away you go. There's some pretty incredible speed increases(100-200x) but obviously it's incredibly fragile and complex to get right.
Flatbuffers does a good job of trading off fragility for usability by encoding offsets in the placement data. Reading data is slightly slower due to needing to calculate the offset into the data but on the plus side it doesn't depend on compiler specific layouts :).
And while Rust does have restrictions for safety, unsafe should give you the power to do anything equivalent C or C++ can do. Of course, many idioms are different, especially for safe Rust.
> Edit(since I can't reply yet to child):
Ah, I see. This isn't my area of specialty, but it _sounds_ like what Cap'n Proto does? Anyway, it doesn't sound impossible, though it might not be the most ergonomic. I'll check out that library, thanks.
Yeah, Cap'n Proto is very similar, FlatBuffers has the advantage in that it compiles against almost all versions of Visual Studio where Cap'n Proto unfortunately decided to use some C++14 features.
FWIW I think I've seen some ports of FlatBuffers into Rust since it's much easier to handle due to the offsets and translation on return value. The former(matching compiler layout) was the part that I was mentioning that seems like something a bit gnarlier than rust would like.
Just stick with C if you need low level control.
I think that they'll get there but it's going to take a bit.
Also, I'm not aware of anything that has a wider set of compile targets(all the way to some larger uC up to web via emscripten).
My way, today, to avoid complexity in C++: Avoid C++!
C++ is at least three languages and the complexity is at least that of three languages. If you really want to be faster at programming and don't need to have the last 5% of performance, do you a favor and use an other language.
It goes without saying that modern fortran is a hideous language (even though it's still better than Fortran 77). C is nice and simple but without things like namespaces and classes you're going to end up with huge function names. Not to mention a high risk of memory leaks.
C++ was awful years ago. Honestly C++11 allows you to write fairly nice code. By no means a guarantee you'll write clean-ish code, but it definitely gives you the tools to do so. Plus modern C++ compilers produce really fast code (that leverages SIMD/vectorization, etc.).
I'm a huge fan of Go and Rust but the former is often dogmatically minimalist to the point of not including things like templates, operator overloading, etc. Not to mention garbage collection/runtime which is a big no-no for numerical computing use. The latter is still not mature enough to fully commit to (and is nowhere near the speed of optimized C/C++).
> (and is nowhere near the speed of optimized C/C++).