4 ms·
Why does it seem like C++ is constantly replacing its subtle hazards with even more subtle hazards? It's like they never go away, they just turn into something
by throwaaskjdfh 5y ago
Why does it seem like C++ is constantly replacing its subtle hazards with even more subtle hazards? It's like they never go away, they just turn into something more obscure.
- Koshkin 5y agoWell, no doubt it all comes from good intentions. (With which, you know, the road to hell is paved.)
- plorkyeran 5y agoThis is an example of a very old subtle hazard that has been removed entirely (the ordering which causes problems is no longer permitted in C++17).
- deleted 5y ago[deleted]
- pshc 5y agoIt’s Stroustrup’s Full Employment Theorem in action.
- AnimalMuppet 5y agoIn addition to what plorkyeran said, "more obscure" can mean either "harder to understand" or "less often encountered". The second one is progress.
- Kranar 5y agoBecause the people involved with C++ have a toxic aversion to learning from other languages. Anytime issues are brought up the people involved with C++ standardization keep yapping the line that "But C++ is not like <other language>." and then proceed to implement a half-assed version of what other languages have and then 2-3 years later people find all kinds of footguns that could have simply been avoided had proper research been performed. The big issue is that becoming involved in the C++ standardization process is purposely arcane, requiring people to physically travel to remote locations, miss time off work, and spend a lot of money. There are literally substantial language features added to C++ that are nothing more than the work of maybe 3-4 people. These features could have benefited enormously from having 100s, if not 1000s of potential developers exercising use cases and contributing suggestions, but the standardization process is heavily gated.
- duped 5y agoI feel like this is a strawman. 9/10 times when there is resistance to a particular feature it's because implementing it breaks the ABI. > requiring people to physically travel to remote locations, miss time off work, and spend a lot of money. It's a different kind of barrier to entry, but I would be surprised if the attendees of the standards meetings aren't being compensated for it.
- UncleMeat 5y agoYup this is the core problem. What should C++ prioritize? 1. Backwards compatibility with already existing binaries? 2. Speed speed speed? 3. Ergonomics?
- deleted 5y ago[deleted]
- overgard 5y agoWait I thought C++ never even specified an ABI? Isn't name mangling and calling conventions left to the implementation?
- initplus 5y agoThere is a large culture among C++ users of distributing pre-compiled binaries of dependencies. See every Linux distribution, or the MSVC ecosystem where sharing precompiled .dll's is the norm. In this context ABI breaking changes are not viable due to the proliferation of pre-existing compiled binaries. What the standard says is only half the story...
- pjmlp 5y ago> There is a large culture among C++ users of distributing pre-compiled binaries of dependencies. See every Linux distribution, or the MSVC ecosystem where sharing precompiled .dll's is the norm. That is why I can code on the go in C++ on my travel netbook, while I mostly use Rust when plugged, or have to do a full build before leaving.
- overgard 5y agoI think the simple reason is that developer ergonomics are the last priority. Zero cost abstractions and expressive features win the day even if you need to hold 19 obscure things in your head to use it right. (I like C++ btw, but it's not a friendly language). I guess those values kind of work though.. I mean, we keep using it.