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

[pal666]

C++ produces code that is slower than C

wrong. c++ can produce exactly same code as c. technically it does not support restrict, but compilers do

while Rust regularly produces code that is on par with C

lie again. rust is slower than c++

wall of mindless rust propaganda skipped

If C++ were re-created today from scratch, it would be Rust.

if c++ were re-created today, it would have some changes indeed. but it would be still compatible with c. so it will be used while rust will not.
rust zealots advertise "c++ killer" without understanding c++ guiding principles

In the end, you'll just end up as all other C++ programmers: fleeing from C++ to Rust because Rust offers safety, speed, and features that you could never get with C++.

lol, how many millions of c++ programmers fled to rust? i only see few "c with classes" programmers, i.e. people who failed at c++. they will fail at any complex task

[pal666]

I think he means, using C++ features like virtual methods causing cache misses. I remember my C++ friends talking a bit more, but I can't think of anything else on top of my head.

but as correctly pointed out, it is bullshit. if you write classes in c manually, you will have same performance, but with tedious and error-prone work. and if you will not write classes in c, you don't need virtual methods in c++ either. maybe you are java programmer?

[pal666]

C features a restrict keyword which can be used to avoid aliasing as Rust achieves out of the box. C++, on the other hand, does not feature such functionality.

technically it doesn't, but in g++ you can use __restrict__. surely it is better than rewriting in rust

In example, vectors in C++ cannot use realloc

vectors in standard library, not vectors in c++. in c++ you can write vector which can use realloc. or even better stuff.

, but vectors in Rust can and do use realloc

but it does not mean rust vectors are faster

In another example, move semantics in Rust is cheaper than the same in modern C++ when opting into move semantics, but Rust's move semantics operate entirely differently in a more efficient/practical manner.

rust does not have move semantics. it has move kludge. btw, you can't use realloc with real move semantics. though you can't use it for anything with non-trivial copy constructor either

[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?

[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]

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

[pal666]

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

[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]

btw, if constexpr came from d

[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.