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.
C++ Modules Are Here to Stay
121–130 of 143 posts
Re: C++ Modules Are Here to Stay
#122Earlier 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.
Re: C++ Modules Are Here to Stay
#123Earlier 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.
- import macro-defined;
- import BS.thread_pool;
Re: C++ Modules Are Here to Stay
#124Earlier 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.
Re: C++ Modules Are Here to Stay
#125Earlier 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…
but in the rare case you need code like that be glad C++ has you covered
Re: C++ Modules Are Here to Stay
#126Earlier 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.…
Re: C++ Modules Are Here to Stay
#127I 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.
Re: C++ Modules Are Here to Stay
#128Earlier 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.
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
#129Earlier 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.
[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
#130Earlier 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