Hacker News Reader

Comment by TimorousBestie | Hacker News Reader

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.

> whine to your vendors until they give you the new stuff.

How well does this usually work, by the way?

Nobody is "whining" to you. Nobody is mentioning rust. Your tone is way too sharp for this discussion.

If C++ libraries eschew backward compatibility to chase after build time improvements, that’s their design decision. I’ll see an even greater build time improvement than they do (because I won’t be able to build their code at all).

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.

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

Its happening again with contracts. Implementers are raising implementability objections that are being completely ignored. Senders and receivers are being claimed to work great on a GPU but without significant testing (there's only one super basic cuda implementation), and even a basic examination shows that they won't work well

So many features are starting to land which feel increasingly DoA, we seriously need a language fork

Please make one.

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 works so poorly. My solution is to wrap it in a struct so that at least one aligned type is involved and so that static_assert can query it.

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

> and why the correct answer is what it is is critically important to that line of code working correctly.

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

I strongly disagree. alignof(buf) works correctly but is a GCC extension. alignof(decltype(buf)) is 1, because alignas is a giant kludge instead of a reasonable feature. C++ only barely has me covered here.

When one of the main arguments people use to stick to C++ is that it "runs everywhere", it actually is. After all, what use is there for a C++ where the vast majority of the library ecosystem only works with the handful of major compilers? If compatibility with a broad legacy ecosystem isn't important, there are far more attractive languages these days!

Just like Python was to blame for the horrible 2-to-3 switch, C++ is to blame for the poor handling of modules. They shouldn't have pushed through a significant backwards-incompatible change if the wide variety of vendor toolchains wasn't willing to adopt it.

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.

Nobody uses all features of C++.

But you might not be able to use libraries that insist upon modules. There won't be many until modules are widespread.

This is not an argument against modules. This is an argument against allowing areas that don’t upgrade hold modern c++ back.

Reply on news.ycombinator.com