Why 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.
What to do with C++ modules?
11–20 of 269 posts
Re: What to do with C++ modules?
#12Back 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…
It seems particularly tricky to define a template in a module and then instantiate it or specialize it somewhere else.
Re: What to do with C++ modules?
#13Why 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?
#14Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.
Re: What to do with C++ modules?
#15Re: What to do with C++ modules?
#16Earlier quoted context omitted.
C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add , but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant`…
variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic.
C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use.
Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.
Re: What to do with C++ modules?
#17Earlier 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.
Re: What to do with C++ modules?
#18The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c
Re: What to do with C++ modules?
#19Why 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?
#20Back 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…