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

81–90 of 269 posts

Re: What to do with C++ modules?

#81

Post by MindSpunk »

ozars wrote: post #71
diath wrote: post #23

Earlier quoted context omitted.

There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.

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 imposes 'restrict' semantics on even single threaded code you end up making it much harder to write code in these domains.

This has been my experience with Rust. Shared mutability is safe on a single thread without 'restrict' on all your pointers, and Rust has limited options to opt into shared mutability (with lots of ergonomic caveats).

Don't get me wrong though, I still think Rust is a great tool. It just has tradeoffs.

Re: What to do with C++ modules?

#82

Post by Dylan16807 »

tandr wrote: post #44
InCom-0 wrote: post #25

Earlier quoted context omitted.

Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).

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

That's not devil's advocate, that's just being silly.

Re: What to do with C++ modules?

#83

Post by cyberax »

tsimionescu wrote: post #41
StephenHerlihyy wrote: post #35

Modules provide more than just speed. Compile time benefits are great and the article is right about build-time bloat being the bane of every developer. But modules serve a deeper purpose. Explicit sub-unit encapsulation. True isolation. No more weird forward declarations, endlessly nested ifdef guards, or insane header dependency graphs. Things just exist as they are separate, atomic, deterministic and reliable. Mod…

Use a feature that doesn't really work, after so many years, hoping compilers will actually make it work if people use it - seems like a disastrous plan. People have tried to use modules, and have generally found that they fail, and have dumped them. It's unlikely at this point modules in their current form will ever be anything but a legacy feature in C++. Maybe someday a new implementation will arise, just like noe…

Or a more relevant example: export templates.

Re: What to do with C++ modules?

#84

Post by pizlonator »

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 with any other tech

Re: What to do with C++ modules?

#85

Post by sfpotter »

jjmarr wrote: post #69
WalterBright wrote: post #45

Earlier quoted context omitted.

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.

"if constexpr" introduces a new scope, while "static if" does not. A major divergence, enough to make the features very, very different in terms of what they can actually be used for.

Re: What to do with C++ modules?

#86

Post by ra1231963 »

okanat wrote: post #7
holowoodman wrote: post #2

Why 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 la…

I believe with a little (okay a lot of) motivation and a solid LLM, these can all be rewritten faster than everyone says. Especially if it’s gradual.

Mozilla and Dropbox did it. LLMs are good at translating between languages, and writing unit tests to make sure things still work the same.

Re: What to do with C++ modules?

#87

Post by mtoner23 »

WalterBright wrote: post #47
emtel wrote: post #33

I did C++ for over 10 years, and now have been doing rust for about 4. On the whole, I like rust much better, but I really miss header files. Modules are horrible for build times. If you change an implementation (i.e something that would not normally involve editing a header) the amount of rebuilding that happens is crazy, compared to any C++ project that was set up with a minimal amount of care.

D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.

[flagged]

Re: What to do with C++ modules?

#88

Post by RossBencina »

nurettin wrote: post #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.

> If you avoid circular refs

See the book "Large Scale C++ Software Design" by John Lakos for more detail in this direction.

Re: What to do with C++ modules?

#89

Post by nurettin »

ozars wrote: post #71
diath wrote: post #23

Earlier quoted context omitted.

There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.

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

Yes, you could just use Arc everywhere. But then you've spent a large portion of your coding time fighting the compiler and wasting lines for something that will essentially always be single threaded. (a UI event loop)

The C++ solution would be to start the threads and use an MPSC queue (which, ironically, Rust also has) in order to update the UI.

Rust will eventually stumble upon ergonomics and allow portions of code to be specified as single threaded or embarrassingly parallel, but unfortunately the community evolved horse blinders early on and isn't letting them go any time soon.

Re: What to do with C++ modules?

#90

Post by jjmarr »

emtel wrote: post #33

I did C++ for over 10 years, and now have been doing rust for about 4. On the whole, I like rust much better, but I really miss header files. Modules are horrible for build times. If you change an implementation (i.e something that would not normally involve editing a header) the amount of rebuilding that happens is crazy, compared to any C++ project that was set up with a minimal amount of care.

Changing the private module fragment (equivalent of a source file) shouldn't cause rebuilds since it doesn't change the interface.
Post reply on HN