News for hackers. Stuff that matters.
Re:On the history and justification of the C programming lan... by stcredzero on Thursday August 18, 2016 @01:38PM (#12314657)
It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability.

What language has all of these covered? (Rust?)

Re:On the history and justification of the C programming lan... by ThatGeoGuy on Thursday August 18, 2016 @01:54PM (#12314789)
> branching

None that I know of from the last 20 years or so.

> inlining

This one is tricky. Sure, GCC ignoring the inline keyword is annoying, but sometimes figuring out if something is inline-able is undecidable, and sometimes things just aren't capable of being inlined.

> blocking inlining

This is something that I don't understand why we don't have. Sure, lots of times you would rather inline than not, but sometimes inlining the wrong expression can subtly change the performance / lookup / dispatch semantics in weird ways. I've no hard examples of this, but it should be easy enough for almost every language to have a --no-inline flag.

> RVO

C++11 and up somewhat handle this with move semantics. Having a separation of rvalues / lvalues certainly helps, but the distinction could probably be clearer, as it can get to be a gruesome and hairy topic depending on your types.

> const != immutability

That you can often just "cast the const away" is really the problem here. I think Rust improves on this space as there is no safe cast to remove const-ness, but if you ever find yourself or somebody else casting away const, you / they should realize that they are going against the design of the system. I'm still undecided if "mutable" keyword in C++ classes is so horrible in this context, as it certainly helps in making const-types usable with the rest of the language (which is inherently non-const).

Re:On the history and justification of the C programming lan... by AnimalMuppet on Thursday August 18, 2016 @02:38PM (#12315201)
Well, in C++, "const" isn't actually intended to mean "literally const", it's supposed to mean "const in spirit". You can be const and still change some of the bits of an object if that change doesn't (semantically) change the object. To be able to do that, you need to be able to cast away const-ness. (No, I can't think of a reasonable example at the moment.)

It would be fair to ask whether that intent was a good idea. It would also be fair to point out that many (most) times people cast away const-ness simply out of expediency, rather than using it the way it was intended.