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

[coder]

As a long-time C++ user, working my way through Scott Meyers' Effective Modern C++, I'm left with the feeling that C++11 already went too far. I loved Meyers' earlier "Effective" books and felt like a fairly modern C++ user (I've use lots of boost and dabbled in template metaprogramming), but this latest addition to his cannon just feels like a heavy slog through a lot of dense, esoteric details. And I don't think that's Scott's fault.

C++ produces code that is slower than C

In theory, features like exceptions and RTTI can add overhead that makes C++ slower. In practice, what I think we see is the average C programmer producing worse code in C than C++, because it's a lot more work (and more error-prone) to use the best algorithms and datastructures in C.

Another point is how template specialization enables special-case optimizations that would be impractical to do by hand. I've certainly taken advantage of this capability, in vectorized signal processing code.

On the flip side, C++ makes it very easy to write slow code. Heap allocation is often hidden, and copies are so effortless that programmers often do them as a matter of course. A few years ago, I became keenly aware of this, while hacking on x264 (a popular video codec written in C and assembly). They never copied anything, instead preferring to pass everything through a small number of context structures. This was practically as bad as using global variables, as it often made data flow very hard to follow, further adding to the code's impenetrability. The one benefit was performance, although the size of these structures eventually resulted in some fairly hopeless issues with L1 (and I think even L2) cache thrashing. Of course, if you're careful, you can avoid copies in your C++ code. It's just a matter of knowing where copies are likely to hurt, and discipline. And C++11 did give us important new tools to help with this.

Switching sides, yet again, C programmers still use too many fixed-sized arrays. C++'s heap-allocated std::string and std::vector might be slower, but they play an important part in helping to avoid many buffer overrun bugs and exploits. And if you wanted the performance of stack-allocated buffers, but the safety of heap-allocated structures, you could write a custom string template to let you specify the expected size and have it automatically overflow to the heap (or fail in some other robust way). Last time I checked, GCC's std::string had a built-in buffer that was hard-coded to something like 6 bytes. Also, CoW optimizations.

[ldo17]

se the advanced features in editors. eclipse just recently got usable with C++11, the indexer would often crash with C++11 code before.

Sounds like what you call an “editor” is just getting in your way. Trying to be too helpful, perhaps? Trying to do complicated GUI stuff, instead of just letting you get on with editing text?

[ldo17]

Those if- and switch-inits look like complicated ways to achieve an effect that can be done much more simply by having a general form of statement blocks in expressions. BCPL (the granddaddy of C) had this decades ago, e.g.

A := valof §( let B = func1() and C = func2(); resultis B + C §)

[patstew]

Not extensible enough (hardware debugging?)
Dunno, but the constant nonsensical hype comparing it to 30 years old C is bugging me.

Just FYI, QT Creator does support hardware debugging, for remote linux and bare metal embedded type stuff.

[pal666]

btw, if constexpr came from d

[tinko]

I am personally tired of C++ and its constructs. They seem highly artificial and get in your way most of the time.

Well, the constructs do not really have agency or can turn up in your source code on their own. They can only get in the way, if they are used. If they get in the way they probably should not have been used in that situation. And many features are really specialized and shouldn't be used most of the time. For example, when I am not designing some new abstraction (which happens very, very rarely because there are so many good libraries for so many domains already), I really don't use the keyword "template" at all, and I'm also not thinking about R-value references or writing a move-constructor or anything like that.

I do use range-based for loops (for(const auto& element : container) {...}, C++11), auto (C++11), generic lambdas (C++14), and constexpr (with features that are only allowed since C++14). Those are all helpful, make my code more readable and less error-prone and they are relatively new constructs (at least compared to "C with classes".

The set of rules to remember is just enormous! I personally prefer to use it as "C with classes" (or a well-defined subset to agree on during a project). That's probably not the best use of it, but at least the code stays understandable.

The good thing is, that you do not have to remember all rules. More importantly, those who design the new features, do not want you to memorize the standard or to use all the features, that have ever been created. I think the strategy has explicitly been stated to be "supersetting and subsetting" in a presentation by Stroustrup, Sutter or somebody else of the C++ gurus. To advance, they need to support the modern ways, but they have to keep the backward compatibility, so they are mostly forced to add new features to the language mostly without changing the old stuff (creating a superset of the previous instance of the standard). After those features are supported and established, they can enable superior ways to write certain code and the subset that is the "best practice" of C++ will include some (or hopefully most) of the most recent features, but it might no longer include some of the old features.

Using a well defined subset of C++ is a good choice and certainly the right thing to do. But I'd argue that "C with classes" as a subset is a poor choice and I am surprised that you would pick this subset and, at the same time, you are tired of C++ and want to learn Rust. A major selling point of Rust is memory safety. If you like that aspect, you'd probably like a subset of C++, that is not "C with classes".

For example: My programs do not include the words "new" or "delete" or C-style arrays. In a larger program, written by multiple people, those are basically a guarantee for memory bugs. Instead, I use std::unique_ptr (so far I managed to come up with designs that avoided the necessity of std::shared_ptr), std::array and std::vector.

I know very few developers (if any) that knows every feature (or rule) of the language. And I am not sure about you, but I usually need to know exactly what my tools are capable of to be effective with them.

Sorry for the small rant...

I do not believe that. 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.

On topic: I'm also very happy to see if constexpr.

[pal666]

on topic: many nice additions, but if i had to select best one, it would be if constexpr

[pal666]

obligatory link to vectors and realloc https://www.youtube.com/watch?v=LIb3L4vKZ7U
and to d

[VikingGe]

Jesus christ, why is there always a discussion between the same people about why Rust and C++ are both great and shit at the same time? In every single thread about any programming language lately?

I think he means, using C++ features like virtual methods causing cache misses

Virtual methods are only used when you explicitly declare them as such.

There might be a few cases where a C programmer would use enums, unions and switch-case-blocks when a C++/Rust/whatever programmer would just throw virtual methods at the problem, but yeah, then we're talking about mispredicted branches versus a possible cache miss. But anyway, most code we write probably isn't even performance-critical...

in c++ you can write vector which can use realloc. or even better stuff.

...except that you might have to explicitly std::move the old stuff to the new location, which is impossible when realloc implicitly frees its old buffer.

[pal666]

most comments that mention Rust aren't coming from it's users, but outside observers to the language.

you mean from rust sect?

In addition, regarding Phoronix, Rust is typically brought up by detractors that are against Rust's adoption.

why detractors would bring it at all? what are you smoking?