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

221–230 of 269 posts

Re: What to do with C++ modules?

#221

Post by quotemstr »

jjmarr wrote: post #210
WalterBright wrote: post #113

Earlier quoted context omitted.

That was a giant mistake on C++'s part, as you cannot do this: static if (feature) { int bar() { betty(); }} ... lots of code ... static if (feature) bar(); Forcing a new scope cuts the utility of it about in half, and there's no way around it. But if you need a scope with D's static if: static if (expression) {{ int x; foo(x); }} the extra { } will do it. But, as it turns out, this is rarely desirable.

I would use std::enable_if or C++20 concepts. Both work fine for selectively enabling functions.

Yes, but not for accommodating missing definitions or platform specific syntax. A true static if MUST allow invalid syntax in branches not taken if it's to fully replace the preprocessor.

Re: What to do with C++ modules?

#222

Post by StilesCrisis »

account42 wrote: post #161
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:…

> 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: https://github.com/pizlonator/fil-c > It's not even possible to link to unsafe code. This makes it rather theoretical.

You’d be surprised! “Lots of software packages work in Fil-C with zero or minimal changes, including big ones like openssl, CPython, SQLite, and many others.”

It wraps all of the typical API surface used by Linux code.

I’m told it has found real bugs in well-known packages as well, as it will trap on unsafe but otherwise benign accesses (like reading past one the end of a stack buffer).

Re: What to do with C++ modules?

#223

Post by StilesCrisis »

reactordev wrote: post #50
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…

That could be said of every additional c++ feature since c++0x. The committee has taken backwards compatibility, backwards - refusing to introduce any nuance change in favor of a completely new modus operandi. Which never jives with existing ways of doing things because no one wants to fix that 20 year old codebase.

My experience has been that everyone _wants_ to fix the 20 year old codebase! But it’s hard to justify putting engineers on nebulous refactoring projects that don’t directly add value.

Re: What to do with C++ modules?

#224

Post by StilesCrisis »

reactordev wrote: post #208
bluGill wrote: post #171

Earlier quoted context omitted.

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

This. This is why C++ is stuck. The effort required to rewrite old shit code (that works, does its job, makes money) is just too valuable to the company so it sits. All vendors must conform or else be shown the door. No innovation can take place so long as Clu has its claws in our company. I empathize. This is where rust could really help but there’s a lot of hate around “new” so it sits. The C++2042 standard will st…

If you think the problem with C++ is that shared_ptr exists, you should probably just use C.

Re: What to do with C++ modules?

#225

Post by fooker »

tialaramex wrote: post #219
fooker wrote: post #209

Earlier quoted context omitted.

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) {}

Great.

template void drop(std::unique_ptr &&) {}

Also, you don’t really need this because of RAII. You can make it simpler, and here’s how you’d do this in C++26.

template void drop(T &&) {}

It can get even simpler!

void drop(std::movable auto){}

Do you see my point about C++ incorporating the good ideas at a glacial pace?

Re: What to do with C++ modules?

#226

Post by aw1621107 »

pizlonator wrote: post #204
saagarjha wrote: post #151

Earlier quoted context omitted.

I don't see anything that makes this impossible. In fact I think this is just a result of nobody making a project of that scale in those languages yet, rather than it being fundamentally impossible.

It doesn't matter if you or I see what makes it impossible. It's a fact that: - Super large software tends to be C or C++ - One of the unique features of C and C++ is the way software is organized (headers and separate compilation). - Attempts to bring other languages' approach to modules to C++ have been a complete disaster. Hence it's an empirical fact that C and C++ have a superior approach to software scaling, an…

> Hence it's an empirical fact that C and C++ have a superior approach to software scaling

I'm not convinced the "superior" follows. What I'm missing is a causal link between your first and second points - super large software could have been written in C or C++ for reasons other than the header/implementation split (especially if the super large software wasn't so super large at first and grew into its size instead of being planned for that size from the start), and somewhat conversely programming languages with header/implementation splits don't necessarily have corresponding super large software (e.g., OCaml, at least publicly?).

Re: What to do with C++ modules?

#227

Post by aw1621107 »

TuxSH wrote: post #141
aw1621107 wrote: post #132

Earlier quoted context omitted.

> The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. I didn't think modules and separate compilation units are (completely) mutually exclusive? It's not like modules force you to use a single compilation unit for all your code; it just changes where the compilation unit boundaries/dependencies are (though to be fair I'm not entirely certain how much heavy lif…

> That's the fundamental limitation of modules systems that supposedly prevents this scaling? Not the person you're replying to but I can see a problem with some dependency chains. Let's say you have: stdlib If you only precompile A.hpp (as is commonly done), the many .cpp files can be compiled in parallel once A.hpp is precompiled, and you get a nice speedup. If on the other hand you need to precompile everything, t…

I'm not entirely sure modules systems must face that limitation. C++'s module system, for example, permits separation of module interfaces and module implementations, much like the existing header/implementation system. IIRC OCaml's module system does something similar, though I'm not familiar enough with it to say whether it qualifies as a module system beyond the name.

Speaking more abstractly even if there isn't an explicit interface/implementation separation perhaps compilers could pick out and make available interface information "ahead of time" to alleviate/possibly eliminate the effect of otherwise problematic dependency chains? For example, in Rust you "just" need to look for signatures to figure out the interface and you have the corresponding keywords to make searching for those easy without having to fully parse the entire file.

There's also the question of whether super large projects must have problematic dependency chains - hypothetically, if a super large project were written in a language with a module system some work would be done to try to structure it to minimize build time/system pain points. I don't think I can confidently say that that is always (im)possible.

Re: What to do with C++ modules?

#228

Post by aw1621107 »

fooker wrote: post #186
tialaramex wrote: post #159

Earlier quoted context omitted.

Concepts is a particularly hilarious example because what you got in C++ 20 is Bjarne's "Concepts Lite". Bjarne worked quite hard to get rid of the ideas and people behind the much more powerful C++ 0x Concepts, which resembles Rust's trait feature, and then it took a decade to land his worse alternative. That actually is a microcosmic survey of the problem with the language.

So what you’re saying is that it takes time, but works out? I agree.

> So what you’re saying is that it takes time, but works out?

Probably depends on what you mean by "works out". I don't think GP would agree that delivering a less capable alternative qualifies.

For example, one major feature C++0x concepts was supposed to have but got removed was definition-time checking - i.e., checking that your template only used capabilities promised by the concepts it uses, so if you defined a template with concepts you could be assured that if the definition compiled it'd work with all types that satisfied the concept. That feature did not make it to C++20 concepts and as far as I know there are no plans on the horizon to add that feature.

Re: What to do with C++ modules?

#229

Post by aw1621107 »

fooker wrote: post #225
tialaramex wrote: post #219

Earlier quoted context omitted.

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) {}

Great. template void drop(std::unique_ptr &&) {} Also, you don’t really need this because of RAII. You can make it simpler, and here’s how you’d do this in C++26. template void drop(T &&) {} It can get even simpler! void drop(std::movable auto){} Do you see my point about C++ incorporating the good ideas at a glacial pace?

> template void drop(std::unique_ptr &&) {}

So what happens for objects that aren't behind a unique_ptr?

> Also, you don’t really need this because of RAII.

drop() indeed isn't used much because of RAII, but it is handy for those instances where you do actually want to dispose of something "early".

Re: What to do with C++ modules?

#230

Post by reactordev »

StilesCrisis wrote: post #224
reactordev wrote: post #208

Earlier quoted context omitted.

This. This is why C++ is stuck. The effort required to rewrite old shit code (that works, does its job, makes money) is just too valuable to the company so it sits. All vendors must conform or else be shown the door. No innovation can take place so long as Clu has its claws in our company. I empathize. This is where rust could really help but there’s a lot of hate around “new” so it sits. The C++2042 standard will st…

If you think the problem with C++ is that shared_ptr exists, you should probably just use C.

If that is what you take from it, you missed the point entirely.

I could care less about shared_ptr.

The issue is why should I care? Why is it on the dev to determine how a pointer should work? Why the dev has to go back and refactor old code to be new again? Why can’t the committee build non-breaking changes to the spec? I would rather have compile flags that make a pointer an “old pointer style” vs having to mentally juggle which ptr container to use, when, and why.

This is just one example. Gang of 3, becomes gang of 5, becomes mob of state… It’s just a giant mess.

Post reply on HN