|
| ▲ | jcranmer 4 hours ago | parent | next [-] |
| > 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. |
| |
| ▲ | amluto 2 hours ago | parent | next [-] | | 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. | |
| ▲ | 20k 3 hours ago | parent | prev [-] | | 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 | | |
|
|
| ▲ | crote 4 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | krior 4 hours ago | parent | prev | next [-] |
| Nobody is "whining" to you. Nobody is mentioning rust. Your tone is way too sharp for this discussion. |
|
| ▲ | juliangmp 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | TimorousBestie 4 hours ago | parent [-] | | Yep, this aligns with my experience. I’ve yet to take the plunge into cross compiling with rust though, might have to try that. |
|
|
| ▲ | Joker_vD 4 hours ago | parent | prev | next [-] |
| > whine to your vendors until they give you the new stuff. How well does this usually work, by the way? |
|
| ▲ | TimorousBestie 4 hours ago | parent | prev [-] |
| 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). |
