Live data from Hacker News

What to do with C++ modules?

nibblestew.blogspot.com

91–100 of 269 posts

Re: What to do with C++ modules?

#91
post #71

Earlier quoted context omitted.

Rust has Arc and Weak that can be used for solving it in a similar way C++ does. The primary difference is forcing usage of Mutex to avoid a large class of data race issues IMHO, and that's what makes it harder to get right. Async in Rust is also more mature than C++ coroutines. So there's also that. https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Arc/Weak can only get you so far. The problem I have with Rust in the mentioned domains (gameplay programming, retained GUI, interpreters) is what makes it so good, sharing xor mutability. If you're writing lots of multi-threaded code it's fantastic. If your problem domain is like the ones mentioned it hurts you. These are all highly non-parallel problems. They don't gain much from being parallel, and because Rust im…

> Rust has limited options to opt into shared mutability

The idiomatic Rust equivalent of a C non-restrict pointer is arguably &Cell. The biggest problem with it is library code that takes &mut T when the likes of &Cell might suffice (because potential aliasing does not affect the semantics of what that Rust code is doing), but this is an acknowledged problem and the Rust project will take pull req's that fix it where it occurs.

Re: What to do with C++ modules?

#92

The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. The pre processor and linker, as derided as they are, allow for scaling of software size to extremes not possible with supposedly superior languages’ supposedly superior module systems. Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that…

The Linux kernel is tens of millions of lines, so I'm rather doubtful at the existence of this OS over a billion lines.

Re: What to do with C++ modules?

#93
While I can see compiler authors not wanting to have to turn the compiler into a build system, I'd really appreciate if they did do that. Having to create makefiles or other build artifacts is such a waste of energy for most applications.

Re: What to do with C++ modules?

#94
post #29
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'.

what is this 1 category?

Re: What to do with C++ modules?

#95
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.

Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons.

So I'm afraid no by definition C++ can't adopt Rust's ideas because Rust's ideas were originally impossible C++ ideas.

Re: What to do with C++ modules?

#96

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…

> Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job.

There are also quite a few compiler cache systems around.

For example, anyone can onboard tools like ccache by installing it and setting an environment variable.

Re: What to do with C++ modules?

#97

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

Tools like ccache have been around for over two decades, and all you need to do to onboard them is to install the executable and set an environment flag.

What value do you think something like zapcc brings that tools like ccache haven't been providing already?

https://en.wikipedia.org/wiki/Ccache

Re: What to do with C++ modules?

#99

Earlier quoted context omitted.

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

> Both zapcc and Fil-C could benefit from the involvement of the standards committee.

I think there is a hefty deal of ignorance in your comment. A standardization process is not pull-based, it's push-based.

If you feel you have a nice idea that has technical legs to stand, you write your idea down and put together a proposal and then get in touch with committee members to present it.

The process is pretty open.

> Certainly more useful than anything else the standards committees have done in the past 10 years.

Do you understand the "standards committee" is comprised of people like you and me, except they got off their rear-end and actually contribute to it? You make it sound like they are a robe-wearing secret society that is secluded from the world.

Seriously, spend a few minutes getting acquainted with the process, what it takes to become a member, and what you need to do to propose something.

Re: What to do with C++ modules?

#100

Earlier quoted context omitted.

The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products. Of course, these tools are of interest to the broader C++ community. Thanks for sharing.

I'm not asking the standards committees to develop them for free. They were already developed! I'm saying that the committees should acknowledge their existence, and the fact that they solve some of C/C++'s biggest problems, in some ways better than the committee-blessed solutions. They deserve attention from the committees to direct language evolution in ways that support them better and encourage alternative implem…

> 'm not asking the standards committees to develop them for free. They were already developed!

That's great to hear. It sounds like you have everything set to put together a proposal. Do you have any timeline in mind to present something?

> I'm saying that the committees should acknowledge their existence, (...)

Oh does this mean any of the tools you're praising was already proposed to be included in the standard? Do you mind linking to the draft proposal? It's a mailing list, and all it takes is a single email, so it should be easy to link.

Where's the link?

https://isocpp.org/std/submit-a-proposal

Post reply on HN