我经常听到有人说c++是一种上下文敏感的语言。举个例子:
a b(c);
这是变量定义还是函数声明?这取决于符号c的含义。如果c是一个变量，则ab (c);定义一个名为b的类型为a的变量。它直接用c初始化。但如果c是类型，则ab (c);声明一个名为b的函数，该函数接受c并返回a。
如果您查找上下文无关语言的定义，它基本上会告诉您，所有语法规则的左侧必须恰好包含一个非终结符。另一方面，上下文敏感语法允许在左侧使用任意的终结符和非终结符字符串。
浏览“c++程序设计语言”的附录A，我找不到一条语法规则，它的左边除了一个非终结符之外，还有其他任何东西。这意味着c++是上下文无关的。(当然，每一种与上下文无关的语言也是与上下文相关的，因为与上下文无关的语言构成了与上下文相关的语言的一个子集，但这不是重点。)
那么，c++是上下文无关的还是上下文敏感的?
当前回答
要回答你的问题，你需要区分两个不同的问题。
几乎每一种编程语言的语法都与上下文无关。通常，它是作为扩展的Backus-Naur形式或上下文无关语法给出的。 然而，即使一个程序符合编程语言定义的上下文无关语法，它也不一定是一个有效的程序。为了成为一个有效的程序，程序必须满足许多与上下文无关的属性。例如，最简单的属性是变量的作用域。
综上所述，c++是否与上下文无关取决于你问的问题。
其他回答
我感觉在“上下文敏感”的正式定义和“上下文敏感”的非正式使用之间存在一些混淆。前者有明确的含义。后者用于表示“为了解析输入，您需要上下文”。
这里也有一个问题: 上下文敏感性vs模糊性。
这是一个与上下文无关的语法:
<a> ::= <b> | <c>
<b> ::= "x"
<c> ::= "x"
它是模棱两可的，所以为了解析输入“x”，你需要一些上下文(或者忍受这种模棱两可，或者发出“警告:E8271 - input is ambiguous in line 115”)。但它肯定不是上下文敏感的语法。
有时情况更糟:当人们说c++具有“不可判定语法”时，他们的意思是什么?
真正的:)
斯坦利·沃福德。计算机系统。页341 - 346。
非上下文无关语法最简单的例子是解析包含模板的表达式。
a<b<c>()
这可以解析为任意一种
template
|
a < expr > ()
|
<
/ \
b c
Or
expr
|
<
/ \
a template
|
b < expr > ()
|
c
这两个AST只能通过检查'a'的声明来消除歧义——如果'a'是模板，则前者为AST，如果'a'不是模板，则后者为AST。
这里的一个大问题是术语“上下文无关”和“上下文敏感”在计算机科学中有点不直观。对于c++，上下文敏感性看起来很像歧义，但在一般情况下不一定是这样。
在C/ c++中，if语句只允许在函数体中使用。这似乎是上下文敏感的，对吧?嗯,没有。与上下文无关的语法实际上不需要这样的属性，即您可以提取某一行代码并确定它是否有效。这实际上并不是context-free的意思。它实际上只是一个标签，模糊地暗示了一些与它的发音相关的东西。
现在，如果函数体中的语句根据直接语法祖先之外的定义而被不同地解析(例如，标识符是描述类型还是变量)，如a * b;大小写，那么它实际上是上下文敏感的。这里没有实际的歧义;如果a是类型，则解析为指针声明，否则解析为乘法声明。
Being context-sensitive does not necessarily mean "hard to parse". C is actually not that hard because the infamous a * b; "ambiguity" can be resolved with a symbol table containing typedefs encountered previously. It doesn't require any arbitrary template instantiations (which have been proven to be Turing Complete) to resolve that case like C++ does on occasion. It's not actually possible to write a C program that will not compile in a finite amount of time even though it has the same context-sensitivity that C++ does.
Python (and other whitespace-sensitive languages) is also context-dependent, as it requires state in the lexer to generate indent and dedent tokens, but that doesn't make it any harder to parse than a typical LL-1 grammar. It actually uses a parser-generator, which is part of why Python has such uninformative syntax error messages. It's also important to note here that there is no "ambiguity" like the a * b; problem in Python, giving a good concrete example of a context-sensitive language without "ambiguous" grammar (as mentioned in the first paragraph).
