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

171–180 of 269 posts

Re: What to do with C++ modules?

#171

Post by bluGill »

reactordev wrote: post #68
feelamee wrote: post #57

Earlier quoted context omitted.

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.

we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table.

c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.

Re: What to do with C++ modules?

#172

Post by bluGill »

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.

Re: What to do with C++ modules?

#173

Post by account42 »

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

There isn't much reason to use Rust if you just bypass the borrow checker.

Re: What to do with C++ modules?

#174

Post by account42 »

Philpax wrote: post #14
fooker wrote: post #13

Earlier quoted context omitted.

C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.

A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add , but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant`…

Ergonomics of std::optional and std::variant have nothing to do with bad foundations and all to do with the C++ committee insisting on these being library features rather than language features. I'm sure we will get the syntactic sugar eventually like we did get range-based for loops after having had to deal with macro approximations of foreach forever.

Re: What to do with C++ modules?

#175

Post by flohofwoe »

ra1231963 wrote: post #167
j16sdiz wrote: post #136

Earlier quoted context omitted.

> https://4e6.github.io/firefox-lang-stats/ 12%. Assume the progress is linear (not logarithmic like most cases), we just need 60 more years to migrate those c/c++ code.

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 the actual code base to be translated? Etc etc... eg the idea to use LLMs for migration is quite 'obvious', but the devil must be in the details, otherwise everybody would be doing it by now.

Re: What to do with C++ modules?

#176

Post by flohofwoe »

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.

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 working example of that idea (which also turned out to be a viable cmake replacement for C and C++ projects)

It could even be reduced to compiler vendors agreeing on a convention to compile and run a build.cpp file. Everything else could live in 3rd party code shipped with a project.

Re: What to do with C++ modules?

#177

Post by feelamee »

Maken wrote: post #135
feelamee wrote: post #57

Earlier quoted context omitted.

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

The goal is to be able to import that 20yo battle-tested library into your C++20 codebase and it just works .

there are really a lot of simpler solutions than switching the standard of the whole codebase. E.g. write wrapper which interface doesn't require a new standard.

Re: What to do with C++ modules?

#178

Post by feelamee »

zbendefy wrote: post #154
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…

Thing is (correct.me if Im wrong), that if you use modules, all of your code need to use modules (e.g. you cant have mixed #include and import ; in your project). Which rules out a lot of 3rd party code you might want to depend on.

you wrong You can simply use modules with includes. If you will #include vector inside your purview then you will just get a copy of the vector in each translation unit. Not good, but works. On the other hand. If you include a vector inside the global module fragment, then the number of definitions will be actually 1, even if you include it twice in different modules.

Re: What to do with C++ modules?

#179

Post by jmull »

> the "header inclusion" way is an O(N²) algorithm

Maybe I don't know what they mean by this, but the header inclusion way is O(N*M), is it not? Where N is the number of source files and M is the average number of dependencies each has (as expressed as #includes).

If M is approaching N -- meaning everything depends on everything -- you probably have bigger problems than compile times.

That's also setting aside precompiled headers. Those wouldn't be N^2 either, even when the precompiled header needs to be precompiled.

Re: What to do with C++ modules?

#180

Post by ninkendo »

imtringued wrote: post #164
TylerGlaiel wrote: post #49

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it". Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing i…

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” is a pretty succinct way of putting it.
Post reply on HN