Live data from Hacker News

C++ Modules Are Here to Stay

faresbakhit.github.io

121–130 of 143 posts

Re: C++ Modules Are Here to Stay

#121

Earlier quoted context omitted.

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.

We use trigraphs to be consistent across the language.

Re: C++ Modules Are Here to Stay

#122

Earlier quoted context omitted.

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.

Hey, I really appreciate this site! Independent from my personal opinion on modules, I think it's extremely helpful to everyone to see the current state of development; and you do an excellent job reflecting that.

Re: C++ Modules Are Here to Stay

#123

Earlier quoted context omitted.

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.

Hey, I really appreciate this site! Independent from my personal opinion on modules, I think it's extremely helpful to everyone to see the current state of development; and you do an excellent job reflecting that.

Thanks - import boost.type_index;

- import macro-defined;

- import BS.thread_pool;

Re: C++ Modules Are Here to Stay

#124

Earlier quoted context omitted.

My experience with vendor toolchains is that they generally suck anyway. In a recent bare metal project I chose not to use the vendor's IDE and toolchain (which is just an old version of GCC with some questionable cmake scripts around it) and instead just cross compile with rust manually. And so far its been a really good decision.

Yep, this aligns with my experience. I’ve yet to take the plunge into cross compiling with rust though, might have to try that.

It's been a comfortable journey for me. There's a support library for the arm cortex I'm using so it was very easy to get some LEDs to blink. Obviously we had to implement some drivers manually (UART for example) and there's lots of unsafe code, but overall the language makes a lot of things very nice on bare metal.

Re: C++ Modules Are Here to Stay

#125
post #62

Earlier quoted context omitted.

> If you tools are not updated that isn't the fault of C++. It kinda is. The C++ committee has been getting into a bad habit of dumping lots of not-entirely-working features into the standard and ignoring implementer feedback along the way. See https://wg21.link/p3962r0 for the incipient implementer revolt going on.

Even some much simpler things are extremely half baked. For example, here’s one I encountered recently: alignas(16) char buf[128]; What type is buf? What alignment does that type have? What alignment does buf have? Does the standard even say that alignof(buf) is a valid expression? The answers barely make sense. Given that this is the recommended replacement for aligned_storage, it’s kind of embarrassing that it work…

The only people who write code like that have plenty of time to understand those questions - and why the correct answer is what it is is critically important to that line of code working correctly. The vast majority of us would never write a line like that - we let the compiler care about those details. the vast majority of the time 'just use vector' is the right answer that has zero real world exceptions.

but in the rare case you need code like that be glad C++ has you covered

Re: C++ Modules Are Here to Stay

#126
post #75
post #61

Earlier quoted context omitted.

The C++ committee tries to do features with room for future extension. They believe that whatever you want from sub-modules is still possible in the future - but better to have a small (as if modules is small) thing now than try for perfects. We can argue about submodules once we have the easy cases working and hopefully better understand the actual limitations.

Not to put too fine a point on it: The world has 35 years of experience with submodules. It's not rocket science. The committee just did what committees do. And sure, "future extension" is nice. But not if the future arrives at an absolutely glacial pace and is technically more like the past. This may be inevitable given the wide spread of the language, but it's also what's dooming the language to be the next COBOL.…

That is 35 years of different things tried, some that work better than others, some that are not compatible with others. Trying to figure out what is the best compromise while also making something that doesn't break existing code is hard when there are a lot of people who care.

Re: C++ Modules Are Here to Stay

#127
post #15

I can’t deploy C++ modules to any of the hardware I use in the shop. Probably won’t change in the near-to-mid future. It seems likely I’ll have to move away from C++, or perhaps more accurately it’s moving away from me.

If you tools are not updated that isn't the fault of C++. You will feel the same about Rust when forced to used a 15 year old version too (as I write this Rust 1.0 is only 10 years old). Don't whine to me about these problems, whine to your vendors until they give you the new stuff.

OP isn't whining to you; I'm not sure where you're getting this defensiveness from. They're simply observing the state of their toolchain and, likely, have better things to do with their 24 hours in their day.

Re: C++ Modules Are Here to Stay

#128

Earlier quoted context omitted.

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.

Hey, sorry about that. I find your site very charming. Yeah it takes a few seconds to understand, but that's completely fine imo.

You are excused if the site misleads anybody, just because you published "Estimated completion date: 2195". That's just so awesome. Kudos.

Re: C++ Modules Are Here to Stay

#129

Earlier quoted context omitted.

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.

Indeed. Two PhD students came to see me when the polytechnic I worked for switched from a Dec10 to two IBM 4381s.

[them] How can we get our code to work on the IBM?

[me] (examines code) This only looks vaguely like Fortran.

[them] Yes, we used all these wonderful extensions that Digital provides!

[me] (collapse on the floor laughing) (recover) Hmm. Go see Mike (our VAX systems programmer). You may be able to run on our VAXen, but I can't imagine it running on the IBMs without a major rewrite. Had they stuck to F77 there would have been few problems, and I could have helped with them.

Portability is always worth aiming for, even if you don't get all the way there.

Re: C++ Modules Are Here to Stay

#130
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

Not for things like public/private, static, virtual. Not for inheritance, either.
Post reply on HN