Of all the complaints I can think of regarding C++, the one I care least about is the difficulty in disambiguating the grammar... Languages exist to help humans, not compilers. Of course, C++ often fails in that regard as well.
Aside, a pox on the house of bottom up parsers. Anyone trying to produce useful semantic errors out of a bottom up parser understands how god awful they are to work with. There's a reason both GCC and clang use hand rolled recursive descent parsers...
My first professional exposure to C++ was porting code across every Unix platform available in the late 90s, using a bunch of proprietary compilers. It was hell. Nothing was consistent. And of course, there were no unit test suites, and the programmers thought that if it compiled on HP-UX 9, it'd compile anywhere. So I have a real attitude about how the parsers work.
I have yet to see a reasonable explanation why C++ needs a type-aware compiler to accomplish its goals. I can't think of any other languages with this problem.
You can't assign a category to the tokens in something like "T * p" unless you know whether "T" is a type or not. Suppose you have the following line of code:
T *p;
It means one thing if it were preceded by this, making the line a variable declaration:
struct T;
typedef struct T T;
It means quite another if it were preceded by this, making the line an expression:
The specific details aren't too important. (Another example: "(T)-1" - very different interpretations depending whether we previously had "typedef int T" or "int T=10"). The problem is that a line of code can't be understood, not even at the most basic level of dividing it up into appropriately-categorized tokens and arranging it an appropriate tree-like structure, without having previously interpreted (to some extent) the code that precedes it.
From a practical perspective, this makes the compiler code more complicated, because now the parsed code has to be analyzed and the results fed back to the loop. As well as the obvious negative effects of code that's more complicated, this also means any code analysis tools that work with source code have to themselves do this same work. (For C, this probably isn't too much of a difficulty, but it's still annoying having to keep track of typedef names and so on just so you can parse it! For C++, it's a very big problem indeed, on account of how much stuff you have to keep on top of - and that's why C++ source analysis tools basically never worked properly once you got past a certain level of complexity until people started just using the compiler to do it.)
I don't have an in-depth background in this stuff, so it's possible there are also more abstract benefits from having a grammar that doesn't suffer from this sort of problem.
> Of all the complaints I can think of regarding C++, the one I care least about is the difficulty in disambiguating the grammar
Compile time speed? Refactoring? Jump-to-definition? Autocomplete? Intellisense? Those are all important for UX, and a tricky-to-parse grammar makes those things mighty challenging.
Those are all examples of semantic analysis (which is also a problem with C++, but has little to do with the grammar). A tricky grammar is simply a parsing problem.
There's a reason both GCC and clang use hand rolled recursive descent parsers...
Another thing about recursive descent, besides the ability to generate very specific error messages, is that it's a naturally intuitive algorithm which is very similar to how humans mentally parse. Perhaps that's also why context-sensitivity is not a problem at all, since natural languages are AFAIK all context-sensitive.
Parser generators are complex, generate huge amounts of virtually undebuggable code, and require learning another language, yet are less flexible than recursive-descent. It's clear why they've fallen out of favour in comparison to simpler and more flexible parsing algorithms.
Natural languages are reasonably close to context-free, actually. There are some freaky constructions in Dutch and (some variants of) German that can't be generated by a CFG. They sometimes get called mildly context-sensitive.
Depends. Have computers do what computers do well, have humans do what humans do well. Humans are intuitive. They can make correct decisions from incomplete, ambiguous, or even incorrect data. What humans suck at is precise, repeatable thinking - like parsing. Meanwhile, computers are great at generating repeatable results from consistent data very quickly, but absolutely cannot make decisions. Even conditional statements aren't actually "decisions".
So a language can be hard to parse unambiguously for machines, but it can be pretty straightforward for humans - like pretty much any natural spoken language.
What does Resharper not do for C++ that you'd like it to do? I know there are some areas that aren't as well-covered as the C# version, I'm just wondering in what real-world those make a difference (my experience is relatively short so I'm probably missing things)
Until you realize that there is rarely any proper tooling around the language, which would be really helpful to humans!
I can list clang and cppcheck on Linux, but nothing else so far. Some of the clang related tools still choke on some parts of C++ though, so even that isn't close.
Aside, a pox on the house of bottom up parsers. Anyone trying to produce useful semantic errors out of a bottom up parser understands how god awful they are to work with. There's a reason both GCC and clang use hand rolled recursive descent parsers...