Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'.
> The ratio between what a C++ compiler will accept and what it will produce sane code for is huge.
As is the case for any programming language.
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.
C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.
> I'm interested to hear examples of what you call 'profusion of edge cases'.
For one example, look at the profusion of cases in type deduction, depending on whether one is dealing with a value, an array, a pointer, or one of two different references, and whether qualified as const or volatile.
One might argue that these cases are too prevalent to be called 'corner' cases, but that doesn't exactly help! In C++11 and C++14 there was the indisputable corner case where auto and template type deduction differed with regard to braced initializer lists, though in a rare case of backwards-compatibility-breaking, it has now been fixed [1].
Scott Meyers, for one, has given examples of particular cases in the use of braced initialization, especially in the context of templates, that can be considered corner cases in that they are probably not likely to arise very often in most of the C++ code that is being written for applications.
One fairly common example of a bad C++ design edge case is the “Most Vexing Parse” problem [0].
I frequently find myself constructing objects using the () syntax will produce parse errors as the compiler is expecting a function declaration. Then replacing the () with {} just fixes it. It’s really frustrating that bad design like this is just maintained as a stumbling block for new users, instead of being fixed.
When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.
It would definitely making interop between C# and C++ much easier. It would make interop between C++ and any language much easier. The only way to do it today is to extern "C" everything. It's ugly.
This doesn't work with C either or does it? C has a reasonable ABI so maybe we should get to the point where exchanging C++ libraries is as easy as doing this with C
The point is there is no standard C++ (or even C) ABI because it is not possible to standardize one. At best you can standardize a platform specific ABI. Which is in fact what happens in practice on most platforms, but it is up to the platform mantainers and the C++ standard itself can't have nothing to say.
Regarding the C ABIs, they are the lingua franca for interchange between languages because, a) as C is semantically poor, it is the minimum common denominator, and b) it is often the OS ABI.
Disclaimer: I don't program in C++ day to day, so maybe my experience is atypical.
Moves and rvalue references (and whatever a PR-value is) and even RVO scare me. They make me want to pass pointers around, because at least I know for sure what'll happen then. (And, funnily enough, C++ seems worse than dynamic languages for this -- more magic around function calls and returns than C or Python or JavaScript.)
scare me ... because at least I know for sure what'll happen then.
Which is just because once you learned how pointers behave. Similarly, if you'd just take the time to learn the basics of rvalues, moving, RVO, ..., you won't be scared by them anymore. Might thake longer than pointers, sure, but it's worth it.
Maybe this is just my experience, but it took me far longer to understand the subtleties of move semantics, rvalues, and RVO than to understand pointers and references in C++. And this is not even getting into “universal references” (which I don’t have a comfortable understanding of either)
There's a YouTube video [1] of a great talk by Scott Meyers: Effective Modern C++ (part 1). He covers universal references and how they relate to other kinds of references in either that one or Part 2 [2]. I found the videos very helpful.
Edit - I may have the wrong videos linked. It could be his talk on Universal References [3] that I'm thinking of. It's been a while.
My understanding is that there are partner venders who have old toolchains set up only for C++03 and thus would have to upgrade their toolchains to build our API if we upgraded.
> The ratio between what a C++ compiler will accept and what it will produce sane code for is huge.
As is the case for any programming language.
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.
C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.