Question

我在Delphi中遗漏的一个功能（我希望它完全可能）是我不能让单位自动包含他们的依赖单位。这在c ++头文件中是可能的。例如，在c ++中：

dependentHeader.h：

#include "baseHeader.h"

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

现在回到Delphi：我有一个名为DebugService的单元为了使用它，需要其他单位：DependentUnit1，DependentUnit2。

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

我想要的是能够将DebugService指定为依赖项并且所有依赖项都出现了吗？

所以，换句话说，我想：

uses
  DebugService;

和NOT：

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 ++标准化委员会以当前的速度工作，最迟将在2113年为您提供一个可行的C ++标准（但不是实现）。

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

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

Answer 2

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

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

Answer 3

Delphi中没有与预编译头相当的东西。如果uses在其DebugService部分的声明中使用DependantUnit1和DependentUnit2中的声明，则需要添加其他interface引用，然后使用其声明由其他单位，因此他们依赖于其他单位。如果您可以设计单位以减少接口依赖性，仅使用implementation部分中的相关单位，那么您不必在其他单位{{DependantUnit1和DependantUnit2中包含uses和{{1}} 1}}条款了。但我明白这并非总是可行。

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

Answer 4

 #include "baseHeader.h"

相当于

 {$I baseHeader.pas}

你可以把任何你喜欢的东西放进那个文件里。甚至整个界面部分。

您的问题的另一种替代方法是使用条件定义。

在主项目文件中

{$DEFINE debugMyApp}

在您使用的每个单元中

use 
  abc 
{$IFDEF debugMyApp}
   , additionalUNit1
   , additionalUNit2 
   , etc
{$ENDIF}
   ;

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

4 个答案: