It seems to me that the real issue is not mentioned by the original question. Yes, "a b(c);" has ambiguous semantics; its interpretation depends on whether c is a type. But such ambiguity is not a matter of syntactic correctness.
However, in a function prototype, we can name the parameters. Thus,
a b(c x);
is syntactically correct C++ if c is a type, but not if it isn't. A correct grammar for C++ must deal with this issue, which cannot be settled by a CFG.
Also, a couple of notes.
(1) "Context-sensitive" does not mean "not context-free". In fact, strictly speaking, every context-free grammar is a context-sensitive grammar. And there are grammars that are neither. So the original question should really be restated.
(2) The long answer makes a very important point:
> ... the standard does not attempt to provide a complete formal grammar, and ... it chooses to write some of the parsing rules in technical English.
> What looks like a formal grammar in the C++ standard is not the complete formal definition of the syntax of the C++ language.
Correct me if I'm wrong here but isn't that exactly the line between syntax and semantics? I'd think that
a b(c x);
is syntactically correct C++ but still not valid C++ code (as in: a well defined line of C++). As far as I know, syntax doesn't depend on whether a type or an identifier or whatever actually exists.
No; if "c" is not a type, then there are no grammar rules which will allow you to produce that statement. So, as you parse that text, when you get to "c", you have to ask, "Is 'c' a type?" The answer you get will determine which subsequent grammar rules you apply. That context - having to know something about "c" that was described elsewhere - isn't technically semantics. It's an assertion just that "c" appeared elsewhere in the text, and when we parsed it, it was in a particular location in the grammer (which just so happens to mean it is a type - but the parser doesn't need to know what that means).
An example of syntactically correct, but semantically undefined code is:
*(static_cast<int*>(NULL)) = 42;
The difference between here and above is that there is nothing in the grammar that can tell you "this is an error". It's only an error because of the semantics that we've given to the operations.
I don't think what you've said is precisely true...
a b(c x);
can be syntactically correct even if c is not a type. Trivially, any of the four tokens could be preprocessor definitions. Even if we are talking about preprocessed c++, the following statement is syntactically correct:
Preprocessor tokens: by that logic, just about anything is syntactically correct. I'd prefer to deal with the syntax of a program after the preprocessor is done with it.
Using "new": Yes, that's right. OTOH, if "c" is literally "c", and not a placeholder for something else, then it looks like my statement is correct. More generally, let c be a placeholder for any identifier, and my statement is correct.[1]
However, in a function prototype, we can name the parameters. Thus,
is syntactically correct C++ if c is a type, but not if it isn't. A correct grammar for C++ must deal with this issue, which cannot be settled by a CFG.Also, a couple of notes.
(1) "Context-sensitive" does not mean "not context-free". In fact, strictly speaking, every context-free grammar is a context-sensitive grammar. And there are grammars that are neither. So the original question should really be restated.
(2) The long answer makes a very important point:
> ... the standard does not attempt to provide a complete formal grammar, and ... it chooses to write some of the parsing rules in technical English.
> What looks like a formal grammar in the C++ standard is not the complete formal definition of the syntax of the C++ language.