Live data from Hacker News

What to do with C++ modules?

nibblestew.blogspot.com

11–20 of 269 posts

Re: What to do with C++ modules?

#11
post #6

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.

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?

#12

Back 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…

What has to change in C++ templates for this to work?

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?

#14
post #13

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

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` 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?

#15
If you avoid circular refs and forward declarations by writing hierarchical code, you won't really need modules. In my current project I'm 20+ headers in and still haven't had a circular ref. Just refactor all the commonly used code, decouple with callbacks and you have yourself a nice clean header only library that you can amalgamate and/or precompile.

Re: What to do with C++ modules?

#16
post #14
post #13

Earlier 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`…

optional is heavily used in new codebases.

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?

#17
post #6

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

C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.

Re: What to do with C++ modules?

#18
The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc

The 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?

#19
post #3

Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.

Sarcasm?

These comments only reflect the person's narrow view of the "world", along with a generous dosage of pride to state things about which one does not know. If every OS and driver and much of the backbone of society is "legacy maintenance stuff", then the statement is certainly correct.

Re: What to do with C++ modules?

#20

Back 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…

Did anyone reach out to you for input during the modules standardization process? D seems like the most obvious prior art, but the modules standardization process seems like it was especially cursed
Post reply on HN