A related comment: http://blog.regehr.org/archives/1287
That, or then everybody switches to Rust. :) (hey, I can daydream can I?).
If you want to get people using a Friendly C, you need to start convincing the biggest users of C and C++ that they should give up performance for a simpler dialect of the language. Like politicians responding to voters, compiler authors respond to what their customers demand. Up to now, their customers have demanded performance. It's not their fault for listening to them.
Why would would C++ programmers have to give up anything? You may notice that the frequent complaint (and title of the article) is "undefined behavior in C", and the hypothetical replacement language is "Friendly C", not "Friendly C++". From the point of view of most who are troubled, rightly or wrongly, C++ isn't considered relevant to the problem or the solution.
I think part of the "divide" is that compiler writers (and probably C++ programmers) are more likely to lump C and C++ together. This makes sense, as C++ is mostly a superset of C, and since many of the optimizations being questioned operate at the level of internal intermediate language that's the same for both. But many C programmers don't view them as being the same language at all, and have no opinion on how C++ compilers should operate.
Perhaps what needs to be questioned is assumption that the needs of C and C++ programmers can effectively be served by the same compiler?
(I realize I've responded strongly to two of your comments in a row. I care strongly about the issue, but don't intend this to be an attack. Rather trying to convince you that you're wrong, my goal is just to understand what produces the gap between our viewpoints.)
I presume there are some, but they aren't the sort of thing I have in mind. I'm talking more about the expectations that the users of each language have. For whatever reason, C programmers are much more likely to complain about "broken" optimizations than are C++ programmers.
Of course this isn't absolute, but I think it's undeniably a pattern. I'd guess this is because C has a heritage of being "portable assembly", and thus many programmers have an expectation of a 1:1 correspondence between the code they write and the finished product, and are startled when it doesn't.
In the case of explicit null checks being removed and loops being removed resulting in memory not being zeroed, I think they have a point. Perhaps there is some way to apply different levels of optimization to the code that the programmer writes versus code "generated" code?
I disagree - it is almost entirely their fault for listening to them. Customers usually don't know what they really want. "Faster horses". The whole point of having an oversight committee is to steer the language, and they failed at the task.
Rather than steering towards sanity - which C/C++ badly need - it was steered towards performance at pretty much all costs. The result is a broken language: it is extraordinarily difficult to write correct programs, and assure that a program will continue to compile as intended many years in the future. Sanity, correctness and fragility are exactly the kind of things which oversight should have tackled, but instead we got the opposite.
I say this as a decades-long user and fan of C/C++. But I've come to realize recently that it's a lost cause, because those in the position to fix the language are powerless against the wishes of their customers.
And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations.
I doubt that. Autovectorization certainly does help performance of real code, for example.
> And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations.
I'm not sure what that means; could you elaborate? That sounds like strict aliasing, which is one of the things "Friendly C" is opposed to…
I wasn't aware of that and my idea of it is different.
Aliasing rules help the compiler decide what values have to be reloaded. The stricter those rules less chance there is for pointers to alias the same memory.
Thanks!
What resources are you using to get into Rust? I've been curious for a while, but I'm not sure where to start.
But I think it depends a lot on your previous experience. If you have experience of other languages, particularly c/c++ and some functional style thing like Haskell there isn't that much of a mental barrier IMHO.