C++20 Making Progress On Modules, Memory Model Updates

[gufide]

C compatibility has nothing to do with C++'s popularity. If you think ridding C++ of its C compatibility would make it just like Java/C#/Python, then you don't understand C++ at all.

Do anybody actually understand C++ at all?

On a side note, C++ is working toward a lifetime checker a bit like rust: https://www.youtube.com/watch?v=sjnp3P9x5jA

[cl333r]

Benchmarks are usually flawed, and the Techempower ones are no exception. But in the latest round, https://www.techempower.com/benchmar...=ph&test=query on physical hardware:

Go speed relative to the fastest in each category was: 81.2%, 63.5%, 58.1%, 77.8%, 42.8%, and 100%.

For VM languages like Java, Java's speed relative to the fastest in each category was: 97%, 100%, 91.7%, 79.4%, 81.2%, and 99.9%.

For VM languages like C#, C#'s speed relative to the fastest in each category was: 80.8%, 54.9%, 46.4%, 69.5%, 56.2%, and 99.7%.

C: 93.9%, 78%, 58.8%, 100%, 75.2%, 99.9%.

C++: 95.7%, 62.4%, 48.2%, 64%, 31.7%, 100%.

Rust: 95.9%, 96.5%, 100%, 59.3%, 100%, 99.8%.

So Go and VM languages are too slow? Really? At least in these benchmarks Java is one of the best options, and Go is on average as good as C++ and only behind Java, C, and Rust.

Yeah, Go it's slow. And shitty too!
As a dev who dropped Java after 10 years of development and switched to C++ I know what I'm talking about. I used to bring up these shitty benchmark results just like you!
In benchmarks you're measuring only a small part of the problem, the other part is that the VM kicks in and compiles the stuff not instantly but at some point (application hickups!!) and that JIT also cost ya. And that the VM is yet another layer of exploits and startup time and CPU usage and memory usage and whatnot.
But yeah, Go and Python are good for what they're designed for (interpreted/JIT apps).

[gwgwg]

preprocessing part should be obsoleted.
#pragma once (or ifdef, define header protection) should be build in. modern language should not use preprocessor - end of story. I would also get rid of header files.

Only if you work on toy projects. Real projects need ability for configuration - compiling the same code for different targets. There are workarounds for languages without a pre-processor (i.e. Java), but they are ugly and lead to duplicated code and consequent bugs.

[brrrrttttt]

"- Work on C++ modules is making good progress and they hope to have it approved still for C++20. "

this would be something really interesting. in my opinion, maintaining a c compatibility is brain dead idea that holds c++ back. whole preprocessing part should be obsoleted.

#pragma once (or ifdef, define header protection) should be build in. modern language should not use preprocessor - end of story. I would also get rid of header files.

Good luck writing cross-platform code without preprocessor. What's the replacement for #if 0ing a block of code? Please don't say /* */.

-e- P.S. Replacing simple text processing with something vastly more complicated, with inferior functionality is brain dead.

[re:fi.64]

- Any decent editor should support automated commenting of blocks with a single keypress. They also highlight differently, so it won't look as if the code is still being used.
- Compile-time evaluation as expressed elsewhere is likely going to replace the preprocessor for platform-specific code.

[Anty]

Most of the proposed library additions are worthless without modules. As anyone who has actually tried to use the ranges-v3 library(which the proposal is based on) could tell you the compile times make it unusable.

Honestly, most of the accepted proposals are just circlejerking without adding anything actually useful to end-users.

Wut? You can live without modules - modern CPU are good enough to do their job.
I want coroutines and networking in standard - this is a big deal.

[cen1]

It is amazing how much C++ development has accelerated in the last 10 years.

[carewolf]

Signed integers are now officially two's complient! I asked them to preempt C on this. Finally we can use right shifts without triggering ubsan.

[bug77]

Yeah, Go it's slow. And shitty too!
As a dev who dropped Java after 10 years of development and switched to C++ I know what I'm talking about. I used to bring up these shitty benchmark results just like you!
In benchmarks you're measuring only a small part of the problem, the other part is that the VM kicks in and compiles the stuff not instantly but at some point (application hickups!!) and that JIT also cost ya. And that the VM is yet another layer of exploits and startup time and CPU usage and memory usage and whatnot.
But yeah, Go and Python are good for what they're designed for (interpreted/JIT apps).

Go is not JITted. Java is also working on adding AoT compilation (through GraalVM, I think). Even in its current form, Java usually starts in server mode and does most of the JITting upfront.

[Guest]

It's funny how each of these iterations ('11, '14, '17 etc) were supposed to finally make the language approachable and usable but they only end up making an even bigger more complicated mess. Can't wait to see what kind of messes '20 will introduce.