> modules should be killed and taken out of the standard.
Yes. The C++ standard is an abomination that is both over-specified and wildly under-specified.
Modules are simply never going to work en masse. It is a failed idea.
What to do with C++ modules?
21–30 of 269 posts
Re: What to do with C++ modules?
#22Earlier quoted context omitted.
I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required. Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.
Re: What to do with C++ modules?
#23Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.
Re: What to do with C++ modules?
#24Earlier quoted context omitted.
I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required. Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
It is a pitty that
- GCC switched from C to C++
- CUDA switched from C to C++
But I can understand the decision, and at that time , C++ frontend features and libs were a little bit less horrible.
Re: What to do with C++ modules?
#25Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
Have a look at any serious job postings.
C++ jobs outnumber Rust jobs somewhere around 50:1.
Internet hype meets actual industry reality :-).
Re: What to do with C++ modules?
#26Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history. C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it. Starting with C++17, I think committee has been doing the la…
I understand and empathize with your fear. C++23 added a type with 22 constructors (http://en.cppreference.com/w/cpp/utility/expected/expected.h...), that ought to be enough to strike fear into anyone.
Re: What to do with C++ modules?
#27Obligatory: https://arewemodulesyet.org/tools/
Not great!
Re: What to do with C++ modules?
#28Earlier quoted context omitted.
Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history. C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it. Starting with C++17, I think committee has been doing the la…
I understand and empathize with your fear. C++23 added a type with 22 constructors ( http://en.cppreference.com/w/cpp/utility/expected/expected.h... ), that ought to be enough to strike fear into anyone.
It already has a defect report too: https://cplusplus.github.io/LWG/issue3886 .
Re: What to do with C++ modules?
#29Earlier quoted context omitted.
Rust does not solve any problem existing in expecienced C++ developer career. You dont write modern C++ code in such a way memory leak or dangling pointer is possible at all) This is exactly WHY we dont see a rush movement of C++ developers to Rust throwing away everything for Rust. Rust is trying to solve problems that already not exist 99.9999% of time in modern C++ code style and standards. Also, some day C++ comp…
Thinking that experience with C++'s many flaws will save you from running into them is delusional - just look at the number of CVEs in projects maintained by world-class C++ programmers. No amount of fallible human vigilance will stop you from forgetting the existence of a C++ quirk in the code you're rushing out before heading out for the night. Human oversight does not scale.
This is true ... except that Rust doesn't actually do any better in that regard.
Rust solves 1 category of problems in a way that is not without its costs and other consequences. That is it. There are projects where this is very important, there are other projects where its virtually useless and the consequences just get in the way. It is not magic. It doesn't make anything actually 'safe'.
Re: What to do with C++ modules?
#30Modules are unusable in real projects with real dependencies. Until that changes there’s no chance I’ll look at them.