在Delphi中有类似于c ++预编译头的东西吗？

Question

我在Delphi中遗漏的一个功能(我希望它尽可能)是我不能让单位自动包含他们的依赖单位.这在c ++头文件中是可能的.例如,在c ++中:

dependentHeader.h:

#include "baseHeader.h"

baseHeader.h中包含的任何头文件都可以在dependentHeader.h中找到.另一个例子是预编译头,无论我在预编译头中包含的内容都可用于项目中的所有头文件.这对于在整个项目中包含常用标题非常有用.

现在回到Delphi:我有一个名为DebugService的单元为了使用它,需要其他单元:DependentUnit1,DependentUnit2.

所以在我使用DebugService的每个单元中,我必须手动添加所有其他依赖单元:DependentUnit1,DependentUnit2.

我想要的只是能够将DebugService指定为依赖项并且具有所有依赖项吗？

所以,换句话说,我想:

uses
  DebugService;

并不是:

uses
  DebugService, DependentUnit1, DependentUnit2;

这是可能吗？

谢谢!

Answer 1

讽刺你会问这个,当一个更好的问题是,"为什么C++还没有模块,在2013年".

Delphi的编译单元通常不会分成重复的.h和.cpp文件.您可能已经注意到Delphi单元具有接口和实现部分.这反过来成为真正的模块系统,编译的.DCU文件与C++/C编译器".obj"文件显着不同,因为当遇到"使用UnitX"时,编译器只能非常快速地读取接口区域.

最近,Apple的CLANG/LLVM编译器开发人员开始在最新的CLANG/LLVM C和Objective-C编译器中添加真正模块支持的基础知识.这意味着XCode中的预编译头支持不再是首选的处理方式,因为真正的模块比预编译头更好.你可以说预编译的头文系统就像有一个模块,只有一个模块,作为你很乐意拥有的破旧的kludge,当你不能拥有真正的东西时,称为模块.您可能会说,您是Windows开发人员,您对CLANG/LLVM有何看法？只是有证据表明世界正在慢慢放弃预编译,并最终转向模块.C++标准化委员会,

简而言之,我们可能会说你的问题可能会问,如果无马车将获得功能,允许它加速缓存和燕麦快速部署到马力单位.

我们这里不需要它.我们有一个真正的编译器,支持真正的模块.故事结局.您可能会注意到模块(在clang/llvm中)比预编译头更快.与预编译的头文件相比,它们也不是问题的根源,它们几乎是无穷无尽的疯狂问题源.

Answer 2

预编译头文件没有任何与标准头文件不同的语义含义.它们只是一种优化,可以缩短编译时间.通常Delphi编译比C++编译器快得多,因此不需要优化.

您不能使用单元A并传递使用单元A的所有依赖项.如果要使用单元中的定义,则必须在uses子句中列出.

Answer 3

在Delphi中没有与预编译头相当的东西.uses如果在其部分的声明中DebugService使用声明,DependantUnit1并且DependentUnit2声明interface其声明随后被其他单元使用,则需要添加其他引用,因此它们依赖于其他单元.如果你可以设计你的单位以减少接口依赖性,只在implementation部分中使用相关单位,那么你将不必再包括DependantUnit1和DependantUnit2在其他单位的uses条款中.但我明白这并不总是可行的.

如果您需要在多个单元之间共享代码,最好将该代码移动到其自己的单元/包中.