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

191–200 of 269 posts

Re: What to do with C++ modules?

#191

Post by samiv »

jonathrg wrote: post #26
okanat wrote: post #7

Earlier quoted context omitted.

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 understand and empathize with your fear. C++23 added a type with 22 constructors ( http://en.cppreference.com/w/cpp/utility/expected/expected.h... ), that ought to be enough to strike fear into anyone.

Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.

Re: What to do with C++ modules?

#192

Post by thegrim33 »

imtringued wrote: post #168
Kelteseth wrote: post #140

Earlier quoted context omitted.

Not sure why you are getting downvoted, but this alone would make me switch (Still waiting for Qt moc support): > No more weird forward declarations We c++ devs just have collectively accepted that this hack is still totally ok in the year 2025, just to improve build times.

The only thing that forward declaration buys you is avoiding to include a header, which is not that expensive in C, but thanks to templates something as innocent as including a header can become infinitely expensive in C++.

Forward declaration breaks dependency chains so that you don't need to recompile vast swathes of your codebase anytime an upstream header file is modified.

Re: What to do with C++ modules?

#193

Post by okanat »

samiv wrote: post #191
jonathrg wrote: post #26

Earlier quoted context omitted.

I understand and empathize with your fear. C++23 added a type with 22 constructors ( http://en.cppreference.com/w/cpp/utility/expected/expected.h... ), that ought to be enough to strike fear into anyone.

Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.

C++ standard and deprecation is a contradiction. They almost never deprecate things. Things always go more complex.

Re: What to do with C++ modules?

#194

Post by samiv »

okanat wrote: post #193
samiv wrote: post #191

Earlier quoted context omitted.

Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.

C++ standard and deprecation is a contradiction. They almost never deprecate things. Things always go more complex.

They're deprecating stuff a lot these days. Add in one version and remove in the next.

https://en.cppreference.com/w/cpp/locale/codecvt_utf8.html

https://en.cppreference.com/w/cpp/algorithm/random_shuffle.h...

Re: What to do with C++ modules?

#195

Post by wakawaka28 »

jhasse wrote: post #144
wakawaka28 wrote: post #103

Earlier quoted context omitted.

ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually goo…

I have a cpp file that takes 10 seconds to compile. I change one line. How does ccache help me in this case?

When you do a clean build, it will pull that output from the cache if it has been compiled before and has not changed since. It does not technically speed up compilation of files. It bypasses compilation when it can.

Re: What to do with C++ modules?

#196

Post by okanat »

flohofwoe wrote: post #175
ra1231963 wrote: post #167

Earlier quoted context omitted.

That was my point — with LLMs the progress would not be at the same slope as with people only.

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 code quality and interface flexibility. It is quite difficult without an actual person to translate things.

Re: What to do with C++ modules?

#197

Post by wakawaka28 »

account42 wrote: post #165
wakawaka28 wrote: post #73

Earlier quoted context omitted.

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.

Why should anyone eat apples instead of oranges? ccache doesn't add anything over make for a single project build.

Yes, it does a LOT more than make. You can set it up to cache files for every copy of a project in your workspace. So if you kick off 10 related builds, for example, only the files that differ will be compiled twice. Although I guess it depends on what you mean by a "single project build". Even in the case of one copy, a clean rebuild will use the cache to speed things up.

Re: What to do with C++ modules?

#198

Post by wakawaka28 »

account42 wrote: post #166
wakawaka28 wrote: post #103

Earlier quoted context omitted.

ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually goo…

ccache does not speed up compilation at all, in fact it slows it down. It only speeds up re-compilation of the same translation unit (as in, bitwise identical preprocessed source code) which is often not all that useful, especially when the local development rebuild use case is already covered by make.

ccache hardly slows anything down. It is a thin wrapper around running the compiler. You seem to kind of understand how it works, but it has multiple configurable ways to detect whether a file should be compiled. It does a LOT more than make, which does NOTHING to handle clean rebuilds or multiple builds of similar code in different locations. Unlike make, it does not rely on file timestamps alone to decide whether to rebuild an output.

Re: What to do with C++ modules?

#199

Post by TylerGlaiel »

ninkendo wrote: post #180
imtringued wrote: post #164

Earlier quoted context omitted.

What do you mean by "no context can leak into it"? Do you mean it shouldn't export transitive imports? As in `#include ` also performs `#include ` but `import vector` would only import vector, requiring you to `import iterator`, if you wanted to assign `vec.begin()` to a variable? Or is it more like it shouldn't matter in which order you do an import and that preprocessor directives in an importing file shouldn't aff…

Not GP, but I take it to mean I can’t do: #define private public #import // muahaha Or any such nonsense. Nothing I define with the preprocessor before importing something should effect how that something is interpreted, which means not just #define’s, but import ordering too. (Importing a before b should be the same as importing b before a.) Probably tons of other minutiae, but “not leaking context into the import”…

yeah that, include is a textual replacement, so anything placed before the include is seen by all the code in the include. Not just other preprocessor stuff and pragmas but all of the other function definitions as well. There are some cases where this has legitimate use, but also is one of the main reasons why compilers can't just "compile the .h files separately and reuse that work whenever its included, automatically"

you define #import as "include but no context leaks into it" and that should on its own be enough to let the compiler just, compile that file once and reuse it wherever else its imported. That's like 95% of the benefit of what modules offered but much much simpler

Re: What to do with C++ modules?

#200

Post by modeless »

motorest wrote: post #185
account42 wrote: post #162

Earlier quoted context omitted.

ccache works at a translation unit level which means it isn't any better than just make-style incremental rebuilds when you aren't throwing away the build directory - it still needs to rebuild the whole translation unit from scratch if a single line in some header changes.

> ccache works at a translation unit level which means it isn't any better than just make-style incremental rebuilds when you aren't throwing away the build directory You used many words just so say "ccache is a build cache". > it still needs to rebuild the whole translation unit from scratch if a single line in some header changes. You are using many words to say "ccache rebuilds a translation unit when it changes".…

Zapcc speeds up incremental builds of a single translation unit. And it speeds up clean-cache builds that include the same headers in multiple translation units. Ccache does not. Yes, this is a huge advantage in real situations.

Frankly your attitude in this whole thread has been very condescending. Being condescending and also not understanding what you're talking about is a really bad combination. Reconsider whether your commenting style is consistent with the HN guidelines, please.

Post reply on HN