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

211–220 of 269 posts

Re: What to do with C++ modules?

#211

Post by bluGill »

flohofwoe wrote: post #176
bluGill wrote: post #172

Earlier quoted context omitted.

Build systems are far more complex than anyone thinks. If your build system doesn't cover all the weird things we do it is not usable at all.

But oth, nothing is better at dealing with edge cases and weird things than writing your build scripts in an actual programming language. All that an integrated C++ build system would do is add a new std::build API, and for the compiler to discover a build.cpp file, compile and run that to perform the build. All the interesting "build system stuff" stuff would be implemented as regular stdlib code. See Zig for a work…

Real build systems need to deal with any language. Cargo is a negative on large projects because it has opinions that make things easy for small rust only projects and falls flat on complex projects-

good build systems need to bea real programming language. The more declaritive the better - this is different from the project that often should be a different style

Re: What to do with C++ modules?

#212

Post by tialaramex »

dzdt wrote: post #156
feelamee wrote: post #60

Earlier quoted context omitted.

I often hear about a lot of advantages of D. So I don't understand why it is so unpopular. Probably I need to give it a chance, but I'm unsure that I will find a real job with the D stack.

Most languages that have made it big have been the primary language for a platform that made it big, and it is really the features of the platform more than those of the language that have driven that.

> Most languages that have made it big have been the primary language for a platform that made it big,

I think you're going to want to define "made it big" and then make yourself some lists as this to me sounds like it doesn't have much explanatory power.

Re: What to do with C++ modules?

#213

Post by grg0 »

ShinTakuya wrote: post #150
grg0 wrote: post #22

Earlier quoted context omitted.

Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.

There's nothing inherent about C++ that makes it more suited than Rust for game engines though, Rust supports careful management of memory too. Of course, nothing besides inertia (i.e. Libs, existing code, etc.). And that of course is more than big enough of a reason to stick with it.

Rust supports careful management of memory at the expense of unsafety, at which point that particular area of the code offers no benefit over C/C++, let alone value in a rewrite. There is no type system for reinterpreting bits of memory.

And for the safe parts, the posts that I've read from people who have spent a non-trivial amount of effort with the language do not paint a clear picture either on whether there was really a benefit to the language overall.

So to say that "the world has moved on" in light of all of this is pure hubris.

Re: What to do with C++ modules?

#214

Post by jjmarr »

wakawaka28 wrote: post #73
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:…

Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does. I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.

ccache only caches the individual object files produced by compiling a .cpp file.

C++ build times are actually dominated by redundant parsing of headers included in multiple .cpp files. And also redundant template instantiations in different files. This redundancy still exists when using ccache.

By caching the individual language constructs, you eliminate the redundancy entirely.

Re: What to do with C++ modules?

#215

Post by flohofwoe »

okanat wrote: post #196
flohofwoe wrote: post #175

Earlier quoted context omitted.

Have there been any successful attempts yet of translating 'idiomatic' C++ to 'idiomatic' Rust for a large codebase that has been developed over 30 years? What does the output look like? Does the code look maintainable (because mechanical solutions to translate from other languages into Rust exist, the result is just not what a human would write or ever want to work on). Are the prompts to guide the LLM shorter than…

Idiomatic C++ allows too much "freestyle" and duck-typed code. Rust language basically doesn't support half of the things that C++ allows because there is no type or memory safe ways to achieve them. When translating things into Rust, borrow checker forces you to invert the logic or completely redo the architecture. Oftentimes it requires trying multiple things and evaluating the performance cost, generated machine c…

Yeah that's why I'm very sceptical about any 'LLM will magically fix all the things' claims. The mechanical translations basically work by compiling the source language down to LLVM bitcode and then translating that back to another language, it works but is basically assembly code written in a highlevel language, it loses all 'semantics' and is entirely unmaintainable.

Re: What to do with C++ modules?

#216

Post by tandr »

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 was, but I guess adding /s at the end in these cases is a requirement nowadays...

Re: What to do with C++ modules?

#217

Post by nitwit005 »

bluGill wrote: post #172
nitwit005 wrote: post #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.

Build systems are far more complex than anyone thinks. If your build system doesn't cover all the weird things we do it is not usable at all.

You can just fall back to some other tool in a complex case. That's what people do with a number of other languages.

Re: What to do with C++ modules?

#218

Post by agent327 »

motorest wrote: post #138
agent327 wrote: post #126

Earlier quoted context omitted.

> What value do you think something like zapcc brings that tools like ccache haven't been providing already? It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.

> It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file. I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a probl…

> I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler.

Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks

> To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.

Do you talk down to people like this IRL as well?

> I've been using ccache for years and I never had any problem getting ccache to support template code.

What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.

> if you understand how compiler caches work. Think about it.

There's no need to use "condescending asshole" as your primary mode of communication, especially when you are wrong, such as in this case.

Re: What to do with C++ modules?

#219

Post by tialaramex »

fooker wrote: post #209
tialaramex wrote: post #202

Earlier quoted context omitted.

What developers actually wanted, even years back when C++ didn't have anything named "move" was the destructive move semantic. It's an elegant, easy to understand feature for a language. I like it very much in Rust which has it. C++ didn't get that. The proposal paper at the time says it's impossible (for C++). But what they did propose was the feature you've seen in C++ today, which they call "move", but it has slig…

I am still confused about what you are claiming to be not possible in C++ when you are designing your library. Yes, I understand that there’s a lot of bad code out there and C++ happily enables that. But that was not my point.

Maybe it will be clearer if you read and understand my favourite function from Rust's standard library (its full name is core::mem::drop)

    pub fn drop(_x: T) {}

Re: What to do with C++ modules?

#220

Post by StilesCrisis »

WalterBright wrote: post #155
Gibbon1 wrote: post #108

Earlier quoted context omitted.

I've really wanted that in C for a long time. It seems like a very trivial thing as well.

Yeah, it's actually easy to implement, too. It replaces the preprocesser: #define Q abc.T with hygiene. Once you get used to it, it has all kinds of nice uses.

C++ code generally uses `using` for typedefs. Macro-based typedefs are exceptionally rare and frowned upon.
Post reply on HN