Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to do with C++ modules?

nibblestew.blogspot.com

Post reply on HN
Print view View original

61–70 of 269 posts

Re: What to do with C++ modules?

#61

Post by modeless »

throwawaty76543 wrote: post #37
modeless wrote: post #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:…

> 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 Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job. > The next major advance to be c…

Both zapcc and Fil-C could benefit from the involvement of the standards committee. While both are very compatible, there are certain things that they can't fully support and it would be useful to standardize small language changes for their benefit (and for the benefit of other implementations of the same ideas). Certainly more useful than anything else the standards committees have done in the past 10 years. They would also benefit from the increased exposure that standardization would bring, and the languages would benefit from actual solutions to the problems of security and compile time that C/C++ developers face every day.

Re: What to do with C++ modules?

#62

Post by feelamee »

lyu07282 wrote: post #53
tandr wrote: post #44

Earlier quoted context omitted.

Or could it be (or to be a bit of devil's advocate) that Rust projects require only 2% (1/50) of manpower, comparing the same project using C++?

I couldn't even tell if you are joking. Rust is weird, its like a programming language people developed a parasocial relationship with. If a Twitch streamer was a programming language it would be Rust. Perhaps its just people being immature I don't know.

> I couldn't even tell if you are joking

I'm thinking the same about your comment :D

Re: What to do with C++ modules?

#63

Post by fuhsnn »

dgan wrote: post #32
modeless wrote: post #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:…

what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests

Latest version of Fil-C with -O1 is just around 50-100% slower than ASAN, very acceptable in my book. I'm actually more "bothered" by its compilation time (took roughly 8x time of clang with ASAN).

Re: What to do with C++ modules?

#64

Post by feelamee »

InCom-0 wrote: post #29
Philpax wrote: post #9

Earlier quoted context omitted.

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

sure, but don't forget that rust gives us also a nice tooling, functional syntax sugar like pattern matching, enums, monads; and other more or less useful things like explicit lifetimes

Re: What to do with C++ modules?

#65

Post by jandrewrogers »

modeless wrote: post #34
dgan wrote: post #32

Earlier quoted context omitted.

what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests

The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. An…

The design choices that make it slower can’t be mitigated either in theory or practice. C++ competes against other languages that make virtually identical tradeoffs that are far more mature and which have never closed that performance gap in a meaningful way.

For the high-end performance-engineered cases that C++ is famously used for, the performance loss may be understated since it actively interferes with standard performance-engineer techniques.

It may have a role in boring utilities and such but those are legacy roles for C++. That might be a good use case! Most new C++ code is used in applications where something like Fil-C would be an unacceptable tradeoff.

Re: What to do with C++ modules?

#66

Post by feelamee »

holowoodman wrote: post #11
c0balt wrote: 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.

haha, fun fact - Unity is C++ code base. You need to look deeper

Re: What to do with C++ modules?

#67

Post by jjmarr »

fooker wrote: post #12
WalterBright wrote: post #5

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.

Including or importing a templated class/function should not require bringing in the definition. That's why #includes and imports are so expensive, as we have to parse the entire definition to determine if template instantiations will work.

For normal functions or classes, we have forward declarations. Something similar needs to exist for templates.

Re: What to do with C++ modules?

#68

Post by reactordev »

feelamee wrote: post #57
reactordev wrote: post #50

Earlier quoted context omitted.

That could be said of every additional c++ feature since c++0x. The committee has taken backwards compatibility, backwards - refusing to introduce any nuance change in favor of a completely new modus operandi. Which never jives with existing ways of doing things because no one wants to fix that 20 year old codebase.

if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?

You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing.

We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.

Re: What to do with C++ modules?

#69

Post by jjmarr »

WalterBright wrote: post #45
Calavar wrote: post #20

Earlier quoted context omitted.

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

Nobody from C++ reached out to me for the modules. Herb Sutter, Andrei Alexandrescu and myself once submitted an official proposal for "static if" for C++, based on the huge success it has had in D. We received a vehement rejection. It demotivated me from submitting further proposals. ("static if" replaces the C preprocessor #if/#ifdef/#ifndef constructions.) C++ has gone on to adopt many features of D, but usually w…

static if was more or less added in C++17 under the name `if constexpr`. It's not exactly the same since the discarded statement is still checked if not dependent on a template, but like most things in C++, it's similar enough to footgun yourself.

Re: What to do with C++ modules?

#70

Post by monkeyelite »

I absolutely love having headers in C and stronger notions of compilation units. But in C++ you tend to want to push everything into headers to take advantage of generics. This is another problem where a separate code generation step would have been superior to language generics
Post reply on HN