Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Modules Are Here to Stay

faresbakhit.github.io

Post reply on HN
Print view View original

111–120 of 143 posts

Re: C++ Modules Are Here to Stay

#111

Post by zabzonk »

groby_b wrote: post #96
pklausler wrote: post #81

Earlier quoted context omitted.

FWIW, Fortran does have submodules.

I suppose we shall amend to "The determined Real Programmer will fix FORTRAN" ;) But, for the folks who didn't grow up with the Real Programmer jokes, this is rooted in a context of FORTRAN 77. Which was, uh, not famous for its readability or modularity. (But got stuff done, so there's that)

I wrote a lot of F77 code way back when, including an 8080 simulator similar to that written by Gates and Allen used to build their BASIC for Altair. I don't know what language they wrote theirs in, but mine was pretty readable, just a bit late. And it was very portable - Dec10, VAX, IBM VM/CMS with almost no changes.

I think F77 was a pretty well designed language, given the legacy stuff it had to support.

Re: C++ Modules Are Here to Stay

#112

Post by mathisfun123 »

rienbdj wrote: post #19

From the outside looking in, this all feels like too little too late. Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements… one day and the committees seem unable to keep everyone happy or disappoint one stake holder. C++ will be around forever, but will it be primarily legacy?

> Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements…

when people say this do they have like any perspective? there are probably more cpp projects started in one week (in big tech) than rust projects in a whole year. case in point: at my FAANG we have probably like O(10) rust projects and hundreds of cpp projects.

Re: C++ Modules Are Here to Stay

#113

Post by fooker »

pornel wrote: post #104
direwolf20 wrote: post #91

Earlier quoted context omitted.

This is one of those wicked language design problems that comes up again and again across languages, and they solve it in different ways. In Haskell, you can't ever check that a type doesn't implement a type class. In Golang, a type can only implement an interface if the implementation is defined in the same module as the type. In C++, in typical C++ style, it's the wild west and the compiler doesn't put guard rails…

Rust's generics are entirely type-based, not syntax-based. They must declare all the traits (concepts) they need. The type system has restrictions that prevent violating ODR. It's very reliable, but some use-cases that would be basic in C++ (numeric code) can be tedious to define. Generic code is stored in libraries as MIR, which is half way between AST and LLVM IR. It's still monomorphic and slow to optimize, but at…

Rust gets around the shortcomings of its generics by providing an absurdly powerful macro engine.

It's a great idea when not abused too much for creating weird little DSLs that no one is able to read.

Re: C++ Modules Are Here to Stay

#114

Post by nextaccountic »

kccqzy wrote: post #52
senfiaj wrote: post #48

Earlier quoted context omitted.

I still hope that modules become mature and safe for production code. Initially I coded in C/C++ and this header #include/#ifndef approach seemed OK at that time. But after using other programming languages, this approach started to feel too boilerplate and archaic. No sane programming language should require a duplication in order to export something (for example, the full function and its prototype), you should wri…

> No sane programming language should require a duplication in order to export something (for example, the full function and its prototype) You are spoiled by the explosive growth of open source and the ease of accessing source code. Lots of closed source commercial libraries provide some .h files and a .so file. And even when open source, when you install a library from a package from a distribution or just a tarbal…

The .h could have been a compiler output, like the .so

Re: C++ Modules Are Here to Stay

#115

Post by kccqzy »

nextaccountic wrote: post #114
kccqzy wrote: post #52

Earlier quoted context omitted.

> No sane programming language should require a duplication in order to export something (for example, the full function and its prototype) You are spoiled by the explosive growth of open source and the ease of accessing source code. Lots of closed source commercial libraries provide some .h files and a .so file. And even when open source, when you install a library from a package from a distribution or just a tarbal…

The .h could have been a compiler output, like the .so

The C language is too complicated and too flexible to allow that. If you are starting from scratch and creating a new language, this could be a design goal from the beginning.

Re: C++ Modules Are Here to Stay

#116

Post by ofrzeta »

rienbdj wrote: post #19

From the outside looking in, this all feels like too little too late. Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements… one day and the committees seem unable to keep everyone happy or disappoint one stake holder. C++ will be around forever, but will it be primarily legacy?

> Big tech has decided on Rust for future infrastructure projects.

as they say "citation needed"

Re: C++ Modules Are Here to Stay

#117

Post by groby_b »

pklausler wrote: post #102
groby_b wrote: post #96

Earlier quoted context omitted.

I suppose we shall amend to "The determined Real Programmer will fix FORTRAN" ;) But, for the folks who didn't grow up with the Real Programmer jokes, this is rooted in a context of FORTRAN 77. Which was, uh, not famous for its readability or modularity. (But got stuff done, so there's that)

I'm so old, those jokes were about me .

Fogeys unite! ;) (They're about me, too)

Re: C++ Modules Are Here to Stay

#118

Post by groby_b »

zabzonk wrote: post #111
groby_b wrote: post #96

Earlier quoted context omitted.

I suppose we shall amend to "The determined Real Programmer will fix FORTRAN" ;) But, for the folks who didn't grow up with the Real Programmer jokes, this is rooted in a context of FORTRAN 77. Which was, uh, not famous for its readability or modularity. (But got stuff done, so there's that)

I wrote a lot of F77 code way back when, including an 8080 simulator similar to that written by Gates and Allen used to build their BASIC for Altair. I don't know what language they wrote theirs in, but mine was pretty readable, just a bit late. And it was very portable - Dec10, VAX, IBM VM/CMS with almost no changes. I think F77 was a pretty well designed language, given the legacy stuff it had to support.

It was well designed. Hence the "it got stuff done".

But it was also behind the times. And, if we're fair, half of its reputation comes from the fact that half of the F77 code was written by PhDs, who usually have... let's call it a unique style of writing software.

Re: C++ Modules Are Here to Stay

#119

Post by Kelteseth »

srcreigh wrote: post #14
w4rh4wk5 wrote: post #8

https://arewemodulesyet.org/ gives you an overview which libraries already provide a module version.

Wow, the way this data is presented is hilarious. Log scale: Less than 3% done, but it looks like over 50%. Estimated completion date: 10 March 2195 It would be less funny if they used an exponential model for the completion date to match the log scale.

Author here. Sadly, this had to be done, otherwise you would not see anything on the chart. I added an extra progress bar below, so that people would not get a wrong impression.

Re: C++ Modules Are Here to Stay

#120

Post by rovingeye »

direwolf20 wrote: post #98
rovingeye wrote: post #55

Earlier quoted context omitted.

This has been valid C++ since C++ 11

It's unusual. Some, unusual, style guides require it. It's useful in some cases, even necessary in some which is why it was introduced, but not for simple "int"

it's literally the exact same thing. We use trailing return types to be consistent across the language.
Post reply on HN