It's the parser (context dependent) that's hard. The rest is a regular compiler that you can learn to write out of a textbook.

And the parser is hard in pain-in-the-ass terms, not CS theory terms.

https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/...

If the parser is hard to write, that means the syntax is conditional upon previous statements, which I've not seen in the spec. As long as the syntax is Lexical, no real issues parsing. How does the context throw curves?

The example I know is the following line:

    foo * bar;

This is either an expression statement computing the product of `foo` and `bar` or the declaration of a variable `bar` as a `foo` pointer. To solve this ambiguity, you need context: if `foo` is a type available in the current scope then it's a variable declaration, otherwise an expression.

I did say context dependent, which is the opposite of context free.

Yes. May need to back track due to context sensitivity. A quote from the source comments:

    Some C++ constructs require arbitrary look ahead to disambiguate.  
    For example, it is impossible, in the general case, to tell whether 
    a statement is an expression or declaration without scanning the 
    entire statement.

I am sure there must be some devilish source code examples that require an exponential search for the correct parse. Also, has anyone constructed a modern C++ parser in bison which can backtrack?

Gcc 3.3 and before had one, but they decided to write one by hand going forward. I don't think it's reasonable to do so without keeping context.

See here for an example https://news.ycombinator.com/item?id=19017234

Making sure that features are implementable on existing compilers (without major changes to the AST or breaking the ABI for example), is a significant concern for the committee, and often features get dropped for this reason.