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

[phoronix]

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

This past week was an ISO C++ committee meeting in San Diego, which happened to be their largest meeting ever, and they managed to accomplish a lot in drafting more planned changes around the C++20 language update...

http://www.phoronix.com/scan.php?page=news_item&px=Cpp-20-November-2018-Update

[Drago]

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

Just use Go then

[Ananace]

I personally don't quite agree with the hate for header files, though I would love to see a slight change in how they're used. The separation between definition and declaration is one of the things that - to me - really makes C/C++ nice to use, as I don't have to trawl through implementation code - or use a tags system / object browser, just to learn what an application or library allows me to do.

Properly done headers should only really need to describe the available actions one can apply onto objects - the public interface if you will. The rest should - in almost all cases - be migrated to code instead. You, as a user, should - for instance - not need to know how a work queue wraps and unwraps your tasks, or how it does thread signalling - or maybe lockless delegation - to actually run the tasks.
A good example for this would actually be the opaque pointer design in C, where you get a pointer to an implementation-unspecified struct, so you - as the programmer using the library - don't have to worry about what happens below your code. Seeing as the library takes care of all the implementation parts for you.

While it is possible to generate documentation from most languages that don't use this design pattern, it always feels like I'm losing some productivity every time I have to switch between code and documentation that gets displayed in different manners. Moving between an editor and a web-based documentation page for instance, or just going from text editing to trawling through an object browser in the same IDE. Working with well written C++ libraries on the other hand can be really pleasant at times, where I can just open up the header for the object I'm handling to cross reference available methods and comments, without losing my context for even a split second.

[cl333r]

What we really want is Rust without a borrow checker, I'd call it C++ 2.0

[cl333r]

Just use Go then

No, Go can only compete with interpreted or VM languages.

[kpedersen]

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

Maintaining C compatibility is what has made C++ one of the most popular languages (after Java and ...C).
When you want a high level language and don't want to write C bindings for Java, C#, Python etc... C++ is the correct choice.

But it works both ways too, C 20 is getting features that ease compatibility with C++ such as nullptr and a certain type of new casting.

[peppercats]

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. Show of hands, who actually uses the execution policy feature added in C++17 that required a ridiculous amount of time and effort to get into the standard library? Hm? It better be zero because no major standard library even implements it.(1, 2)

And to put some salt in the wound: Absolutely nothing about a builtin sum type/pattern matching, std::variant is verbose trash that is everything wrong with modern C++.

[peppercats]

Maintaining C compatibility is what has made C++ one of the most popular languages (after Java and ...C).
When you want a high level language and don't want to write C bindings for Java, C#, Python etc... C++ is the correct choice.

But it works both ways too, C 20 is getting features that ease compatibility with C++ such as nullptr and a certain type of new casting.

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.

[boxie]

No, Go can only compete with interpreted or VM languages.

This is true. Easy to learn, Easy to get good results - the cost is some performance which you can recover by throwing more hardware at the problem.

Thanksfully most of my use cases fit nicely there

[Michael_S]

No, Go can only compete with interpreted or VM languages.

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.