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

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

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

Unfortunately, there is no language closer to C++. I thought D could have been the one, but it looks like they are driving away from the C++ crowd.

d people are working on c++ committee and bringing good stuff from d to c++

[pal666]

I am personally tired of C++ and its constructs. They seem highly artificial and get in your way most of the time. The set of rules to remember is just enormous!

did you try to compare set of rules of c++ against set of rules of c, java and c#? no, otherwise you wouldn't post such bullshit

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.

it means you are unable to learn

Rust ... doesn't have to carry its backwards-compatibility burden.

that's why nobody is using rust: noone will rewrite their code for new incompatible toy

[pal666]

What is wrong with Rust?

it's a toy. no tools, no libraries, no developers, and requires complete rewrite

[pal666]

there really isnt a good C++ editor out there. except for paid ones ms studio and clion.

i didn't use clion, but vs is no match to eclipse cdt

[volca]

rust is a cool language that will once be used widely, probably, but I don't see the reason to drag it into a discussion about C++17.

I like some features that should be present, namely ranges and structured bindings, (maybe others) but what the hell is with all that stalls when it comes to modules and concepts? I see they are pushing them strongly for C++20, hopefully not to be delayed again. Both are essential to move the developement in C++ forward.

[mmstick]

The one thing that is bad about rust is that its users just don't know when to shut up. Seriously, it seems like almost every topic on this site gets hijacked by someone asking if it wouldn't be better in rust. Maybe it would. Maybe it would't. But certainly the vast majority of programmers out there just doesn't give a flying f*ck about runner-up language-with-one-neat-feature of the day. Do you see people hijacking threads to talk about how much better everything would be in Java, or TCL, or ADA, or assembly? No? Then would you mind not dragging rust into every discussion? Because that is getting really annoying now.

In case you haven't noticed, most comments that mention Rust aren't coming from it's users, but outside observers to the language. In addition, regarding Phoronix, Rust is typically brought up by detractors that are against Rust's adoption. It's rarely ever a genuine comment about rewriting something in Rust. That said, Rust is an open source language and it's adoption is driven by word of mouth. Claiming that you'd rather never see a comment about Rust is simply not a possibility. The more people talk about Rust, the better. If you don't like it, then that's your problem.

Oh, and you're wrong too. C++ does not produce code that is slower than C; it is either on par or faster.

This simply isn't true, and you know it.

And as for your magic-unicorn-compiler: yeah, we remember that one back from the java days. Java was also faster than C... Well, almost... Any day now... When we get the new JIT... Show us the code, and then we'll talk. Preferably in a rust-specific language topic, and not one for another language. And until then I wish you good luck getting it 'as fast as Fortran' https://benchmarksgame.alioth.debian...q/fortran.html

This is purely trolling. In no way, shape, or form, could a GC language running a VM approach C/Rust.

Fortran produces faster machine code than C because it has no concept of pointer aliasing. That doesn't mean that all implementations written in Fortran will be faster than all implementations than C. How many times must it be brought up that the benchmarks game is not a reliable language comparison tool?

Now please excuse me, somebody borrowed my lexical scope and I need to get it back...

So you're admitting that you have one week's worth of programming experience.

[mmstick]

Bullshit. Everything in Rust is inspired by C++ best practices.

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.

If you approach Rust as if it was C++, you're only going to end up confusing yourself.

Good C++ is as fast or slightly faster than C (due to stronger aliasing rules the compiler can use)

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.

because C++ use the concept of zero-overhead abstractions

C++ doesn't go far enough with zero-overhead abstractions. There are a handful of cases where Rust's implementation of a feature has less overhead than the C++ 'zero-overhead' equivalent. In example, vectors in C++ cannot use realloc, but vectors in Rust can and do use realloc. 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. But we also can't forget that C++ has a lot of missing standard features which Rust provides out of the box.

the very same idea inspired Rust to make a modern language that could be as fast as C++ by using the same language guidelines

Zero-cost abstractions were not invented by C++. If you truly want to know what Rust took from C++, that would be RAII, not zero-cost abstractions. That said, RAII in Rust is more sophisticated and thus handles far more cases properly. Rust's version of RAII takes full advantage of move semantics given by the borrowing and ownership model, coupled with traits to define whether a type is `Copy` or not-`Copy`.

starting from scratch with a modern basis and delegating the legacy stuff to foreign bindings

Your last part here is confusing, as there is no legacy stuff, and the purposing of FFI is not for delegating legacy things. FFI is for either importing C libraries or exporting a C ABI so other software projects can link into Rust libraries.