What to do with C++ modules?
nibblestew.blogspot.com
What to do with C++ modules?
1–10 of 269 posts
Re: What to do with C++ modules?
#2Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
Re: What to do with C++ modules?
#3Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
Sarcasm?
Re: What to do with C++ modules?
#4Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
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++ compilers or tooling will get its own Borrow Checker to completely forget about Rust - this will be done just for fun just to stop arguing with rust-fans :)
Re: What to do with C++ modules?
#5Back in the 90s, I implemented precompiled headers for my C++ compiler (Symantec C++). They were very much like modules. There were two modes of operation:
1. all the .h files were compiled, and emitted as a binary that could be rolled in all at once
2. each .h file created its own precompiled header. Sounds like modules, right?
Anyhow, I learned a lot, mostly that without semantic improvements to C++, while it made compilation much faster, it was too sensitive to breakage.
This experience was rolled into the design of D modules, which work like a champ. They were everything I wanted modules to be. In particular,
The semantic meaning of the module is completely independent of wherever it is imported from.
Anyhow, C++ is welcome to adopt the D design of modules. C++ would get modules that have 25 years of use, and are very satisfying.
Yes, I do understand that the C preprocessor macros are a problem. My recommendation is, find language solutions to replace the preprocessor. C++ is most of the way there, just finish the job and relegate the preprocessor to the dustbin.
Re: What to do with C++ modules?
#6Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
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.
Re: What to do with C++ modules?
#7Why 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 language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules.
I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.
Re: What to do with C++ modules?
#8Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
Borrow checker is actually not very good solution for some domains. I remember reading that it would not be good for writing javascript VM like v8. Something about managing memory which lifetime actually depends on others, not rust code.
Re: What to do with C++ modules?
#9Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
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.
Re: What to do with C++ modules?
#10Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
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…
This is a very bad take. Rust does solve very real problems in C family languages.
The number of people I met in Rust conferences that rewriting at least parts of rather big C++ codebases weren't small either.
However, there is still big amount of code that is purely C++. Many of the older code bases still use C++03-style code too. Or they were written in the OOP design pattern golden era that requires huge reactors to adapt functional / modern code. Anything with Qt will not benefit from smart pointers. Even with Qt 6.
Rust cannot solve these problems since the challenges are not purely technical but social too.