import - 语言设计中 'import'和 'include'选择有什么区别？

Question

很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它， visit the help center 。

已关闭 10 年前。

Python 和其他语言使用 import获取外部功能的技术。

C 和其他，使用 include (并且，例如 C++，伴随着 namespace 令人头痛)。

在设计语言时选择其中一种(或者像 Objective-C 一样使用两者)的原因是什么？

我看到 Apple 正在通过 LLVM 的文件提出一些更新/更改，并想知道为什么存在差异。

基于@ delnan的澄清的answer

鉴于有多种方法可以实现 import (直到他回答我才意识到)!include 的总体好处是什么？与 include ？ import技术似乎仅根据给定的路径找到单独的子组件(至少在Python中 - 它的[明显]方法是我所知道的唯一方法)。

import 的其他用途如何方法论与此有何不同？什么时候使用“旧风格”include方法在现代语言设计和实现中有意义(如果有的话)？

Answer 1

C的方法是C++和Objective C简单继承的，定义和实现非常简单(简而言之，“当遇到#include时，将其替换为文件的内容，并继续”)，但存在严重问题。其中一些问题已在您看到的演示文稿(以及其他地方)中提到。有一些习惯用法和最佳实践(也在该演示文稿和其他地方进行了讨论)和次要扩展(#pragma Once，预编译头)可以缓解一些问题，但最终，该方法从根本上来说，它的局限性太大，无法满足软件工程师对模块系统的期望。假装它做了最近的替代品所做的事情(见下文)是一个相当漏洞百出的抽象。

如今，每个对语言设计有意见的人似乎都同意，如果可以帮助的话，就不应该这样做。由于需要向后兼容，C++ 和 Objective C 没有这种选择(尽管两者都曾经并且仍然可以选择添加另一种机制，而 Objective C 做到了)。这是“公平的”，因为它在做出时是一个相当好的决定(它运作得足够好，如果你有纪律，它仍然有点运作)，但世界已经前进并确定了更好的方式将代码拆分为模块，然后将其重新组合在一起。 (请注意，这种方式早在 C 语言早期就已经存在，但显然它们有一段时间没有流行起来。)

您所描述的“导入”技术实际上是一个相当大的设计空间。许多模块系统几乎(但不完全)彼此完全不同 - 其余的仍然有足够的细微差别来毁掉你的一天。它可以是任何东西，从在新范围(Python、PHP)中执行导入的文件到成熟的 ML 风格仿函数。有一些相似之处，因为所有这些模块系统都为每个“模块”(无论在各自的系统中意味着什么)提供了自己的范围/命名空间，(通常)允许单独编译模块，并且通常会不遗余力地修复C 风格文本包含的问题(或创建者在替代方案中看到的任何其他问题)。一般来说，人们能说的就这么多了。