4 ms·
Obligatory links: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html, http://robertoconcerto.blogspot.co.
by to3m 12y ago
Obligatory links: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html, http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasing.html http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasin... (I post these every time this subject crops up. TL;DR - stand up for yourself, and don't let your C compiler treat you like shit.)
- userbinator 12y agoSee also the "maybe it's not the programmers who are being stupid, it's the language that is in need of change" proposal at http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180 with discussion https://news.ycombinator.com/item?id=8233484 https://news.ycombinator.com/item?id=8233484
- lmm 12y agoThere are better alternatives to C if a friendly language is what you want. C has its niche and I don't see C changing, and I've yet to see a "dialect" be really successful. If you're willing to switch to "friendly C", why wouldn't you already be switching to Rust, or D, or even Haskell?
- coldtea 12y agoBecause you might need the low-level, reasoning about memory/cpu/etc capabilities of C -- which Haskell doesn't offer -- but don't want all the undefined behavior and extra unneeded complexity. As of Rust, it's not even 1.0-stable out yet. Even if it was, it would take 4-5 years to mature, get enough support, tooling etc to be something you'd use instead of C/C++ for everything.
- lmm 12y ago> Because you might need the low-level, reasoning about memory/cpu/etc capabilities of C -- which Haskell doesn't offer -- but don't want all the undefined behavior and extra unneeded complexity. Surely if you need that low-level reasoning then you do need unions and strict-aliasing, and for the kernel not to be doing extra zeroing of your memory when you didn't ask for it. If you were willing to accept a factor of 2 overhead, you wouldn't be using C at all.
- pascal_cuoq 12y ago> If you're willing to switch to "friendly C", why wouldn't you already be switching to Rust, or even Haskell? Because you are already using it. You, the median C developer, are already writing code assuming that it will be compiled by a friendly C compiler. Friendly C is one of the most widely used programming languages on the planet as of 2015. The most widely used SSL/TLS stacks are written in friendly C. The “friendly C” manifesto is not intended for C developers, an amazing proportion of whom already write friendly C. The manifesto is aimed at C compiler developers. Friendly C just needs a compiler, or perhaps several of them.
- to3m 12y agoYes. To quote one of the links I posted: "The tl;dr version of this is that the C compiler writers have no idea who their users are, so they keep fucking up working code [...] All of this only hurts the systems-level programmer (and I claim is of dubious value to the high-level guys). Which is why I insist that the compiler writers don't know their own customers. C is a systems-programming language! Why do you want to screw the systems-programmer to help the high-level programmer, when the high-level guy has long since moved to C++ and is bumbling around with STL?" That whole post is worth reading. Though something of a tossed-off ranty blog post, I think it very accurate.
- lmm 12y agoThe only kind of systems-programmer who should be writing C is the kind who is capable of manual memory management. The "optimized DSP kernel loops" usually only possible to write with unsigned arithmetic anyway. And if you're using unions at all it's because you're in a super-performance-critical place, in which case the strict-aliasing rules absolutely are valuable (and "other parts of your generated code are slower than MSVC" is a stupid argument). The problem isn't with C, it's with people using C where it's the wrong tool.
- pascal_cuoq 12y ago> Though something of a tossed-off ranty blog post Touché.