[clishem]

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.

[mannykannot]

> 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.

[1] https://isocpp.org/blog/2014/03/n3922

[2] Scott Meyers, 'Effective Modern C++', pp 52-58.

[zach43]

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.

[0] https://en.wikipedia.org/wiki/Most_vexing_parse

[snarfy]

> C++ is designed by its standards committee...

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.

[maxxxxx]

Definitely agree about the ABI. In C# it's a pleasure to write libraries for others and use other libraries whereas in C++ it's almost always a pain.

[gpderetta]

Standard ABI only makes sense if you are targeting a single system (.NET for C#). That's not the case for C++.

[snarfy]

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.

[gpderetta]

How would exactly an library compiled for 32 bit big endian POWER interoperate with a program written for 64 bit little endian ARM?

[maxxxxx]

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

[flukus]

> I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.

And rust is going down the same path. Looks like c will reign supreme for shared libraries for the foreseeable future.

[repsilat]

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.)

[stinos]

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.

[zach43]

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)

[dcuthbertson]

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.

[1] https://www.youtube.com/watch?v=fhM24zs1MFA

[2] https://www.youtube.com/watch?v=-7qwpuA3EpU

[3] https://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-20...

[banachtarski]

They really aren't that bad... in fact, they're pretty useful. Source: your everyday C++ programmer

[stochastic_monk]

They’re great, really. Yes, it takes effort to master, but then you can generate faster, safer, generic code with much less effort.

Source: Another everyday C++ programmer. There are dozens of us. Dozens!

[verall]

It's unfortunate when your codebase is C++03 only and intends to remain that way for compatabillity with other vendors. Yay for consumer electronics!

[banachtarski]

Out of curiosity what breaks compatibility?

[verall]

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.