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

[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 §)

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

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

[Mateus Felipe]

Why there's C++11, C++14 and C++17 and C is at C11 yet?

[starshipeleven]

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?

That's eclipse's standard behavior.

[carewolf]

It's impossible to see objectively when you're wearing C++-tinted glasses. Very little in Rust is inspired by C++ -- much of it's inspiration comes from functional programming languages, which makes a lot of sense given that the original Rust compiler was written in OCaml, not C++. Claiming otherwise is just wilful ignorance on your part.
.

No the syntax is inspired from functional languages, the idea of zero-overhead and many of the smart pointers and secure programming techniques needed together with a system near language comes from C++ since functional programing languages are usually more abstract.

[ldo17]

Why there's C++11, C++14 and C++17 and C is at C11 yet?

Because complexity begets complexity.

[coder]

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.

This is a valid point: C++ needs restrict! I guess the standards folks are content to let compilers implement this in a nonstandard way. IMO, they should've tried harder to keep C++ as a superset of C.

Now, as for how you get restrict-like functionality without the keyword, the only way I see is by reducing the use of pointers. That seems like it'd come at a tradeoff, elsewhere.

vectors in C++ cannot use realloc,

This seems like the kind of thing clever compilers can work-around. I know that some compilers will cleverly reduce code to a memset() or memcpy() call. To me, it doesn't seem like much of a leap to replace the sequence: malloc(), memcpy(), free() with realloc().

[mmstick]

No the syntax is inspired from functional languages, the idea of zero-overhead and many of the smart pointers and secure programming techniques needed together with a system near language comes from C++ since functional programing languages are usually more abstract.

You're stating that Rust is nothing more than syntax, but you can't have syntax without features that the syntax represents -- features that are completely alien to C++. Every syntax decision in Rust has a purpose. A significant portion of Rust's features were taken functional programming languages, not C++. There's a mistake that many of your kind makes, and that's instantly assuming that Rust is like C++, so when you try to program with Rust as if it were C++, you just end up getting confused at why the Rust workflow works more like Haskell than C++. Rust is most definitely an imperative language for the functional programmer.

Take this from someone who can write modern C++ and has mastered Rust's advanced features. C++ doesn't map 1:1 to Rust at all. Unless you have experience with a number of functional programming languages, such as Haskell, Erlang, and OCaml, you're in for an entire world of learning before you can take full advantage of Rust. You don't have ad-hoc polymorphism in the form of traits, trait generics, trait objects, and associated type constructors (aka higher-kinded types) -- Haskellers will be comfortable with these concepts though. And since when was sum types, pi types, pattern matching and bind guards features that came from C++??? Show a C++ programmer a snippet of a Rust programmer's code and they'll just be confused by Rust's features -- not something you can write off as being nothing more than syntax differences.

[mmstick]

Now, as for how you get restrict-like functionality without the keyword, the only way I see is by reducing the use of pointers. That seems like it'd come at a tradeoff, elsewhere.

Rust achieves this by the use of the borrowing and ownership model, mutable and immutable references, lifetime annotations, and move semantics by default. This provides both safety and speed, whilst also saving memory and encouraging data-oriented designs.