为什么语法允许函数体内的函数声明？
它在SO上创建了很多问题，其中函数声明被误认为是变量初始化等。
a object();
更不用说最令人烦恼的解析了。
是否有更常见的范围隐藏手段（如命名空间和成员）无法轻松实现的用例？
是出于历史原因吗？
附录：如果由于历史原因，继承自C以限制范围，禁止它们的问题是什么？
答案 0 :(得分：2)
虽然许多C ++应用程序仅使用C ++代码编写，但也有许多代码是C和C ++代码的混合。这种混合绝对是C ++在其有用性方面的重要组成部分（包括与现有API的“简单”接口，从OpenGL或cURL到用C语言编写的自定义硬件驱动程序，几乎可以直接使用，只需很少的努力，尝试将自定义硬件C驱动程序连接到Basic解释器是非常困难的）
如果我们通过删除“没有特定值”的东西来开始破坏兼容性，那么C ++就不再有用了。除了在令人困惑的情况下提供更好的错误消息，当然这本身就很有用，很难看出它对于删除它有什么用处 - 当然假设C ++没有用它本身 - 而且我不会如果有时甚至在现代代码中发生（无论出于好的或坏的原因），都会感到惊讶。
一般来说，C ++非常努力地不会破坏向后兼容性 - 在我看来，这是一件好事。这就是为什么关键字static用于一堆不同的东西，而不是添加一个新的关键字，而auto表示现在与C中使用的不同，但它不是一个“新”关键字这可能会破坏碰巧使用其他任何单词的现有代码（这是一个小小的突破，但无论如何都没有人真正使用过它。）
答案 1 :(得分：2)
那么，在函数体内声明函数的能力是从C继承的，因此，根据定义，存在涉及历史和向后兼容性原因的原因。当可能存在使用某个功能的真实代码时，从该语言中删除该功能的参数会被削弱。
人们 - 特别是那些只使用最新版本语言且不需要维护遗留代码的人 - 往往低估了C ++中反向兼容性的强大程度。最初的C ++标准是特别需要保持与C的向后兼容性。作为一个粗略的规则，标准不鼓励删除旧功能，如果这样做可能会破坏现有的代码。但是，如果唯一可能的用法导致无法预防的危险（例如，删除gets()的原因），则可以这样做。
在维护遗留代码时，更新代码库以使用一些现代替换替换旧构造的所有实例通常会产生大量成本。在监管环境中维护大规模代码库时，对于业余爱好者程序员来说可能无关紧要的编码变化可能是非常昂贵的，因为有必要提供正式证据和审计跟踪，即代码的更改不会影响满足其原始代码的能力要求。
某些编程样式可以限制任何声明的范围。不是每个人都使用这样的编程风格，但这种特性在语言中的原因是允许程序员选择编程技术。并且，无论是否支持删除此类功能，都有一定数量的代码可以有效地使用这些结构。这大大削弱了从语言中删除该功能的情况。
这些论点倾向于出现在大规模开发中使用的语言，在监管环境中开发系统等等。在这种设置中使用C和C ++（以及许多其他语言），因此会倾向于为“历史”或“向后兼容”原因积累一些特征。通过提供该特征不在实际使用中的证据，可以提出删除这些特征的情况。但是，由于这个论点是关于证明否定主张的合理性，这很难（所有它需要的是提供持续现实世界有益用法的一个例子，突然出现一个支持保留该特征的案例的反例）。 / p>