有没有类似于c++;Delphi中的预编译头?

有没有类似于c++;Delphi中的预编译头?,delphi,delphi-xe2,Delphi,Delphi Xe2,我在Delphi中错过的一个特性(我希望这是可能的)是,我不能让单元自动包含它们的依赖单元。这在C++头文件中是可能的。 例如,在c++中: dependentHeader.h: #include "baseHeader.h" baseHeader.h中包含的任何标头都可以在dependentHeader.h中找到。另一个例子是预编译头,预编译头中包含的任何内容都可用于项目中的所有头文件。这对于在整个项目中包含经常使用的标题非常有用 现在回到德尔福: 我有一个叫做DebugService的单元

我在Delphi中错过的一个特性(我希望这是可能的)是,我不能让单元自动包含它们的依赖单元。这在C++头文件中是可能的。 例如,在c++中:

dependentHeader.h:

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

现在回到德尔福: 我有一个叫做DebugService的单元 为了使用它,需要其他单元:DependentUnit1、DependentUnit2

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

我想要的只是能够将DebugService指定为一个依赖项,并使其所有依赖项一起出现

换句话说,我想:

uses
  DebugService;
而不是:

uses
  DebugService, DependentUnit1, DependentUnit2;
这有可能吗


谢谢大家!

预编译的头没有任何不同于标准头的语义含义。它们只是为了提高编译时间而进行的优化。通常,Delphi编译比C++编译器快得多,因此不需要优化。
您不能使用单元A,也不能过渡地使用单元A的所有依赖项。如果要使用单元中的定义,必须在uses子句中列出。

Delphi中没有与预编译头等效的定义。如果
DebugService
在其
接口
部分的声明中使用了来自
dependentUnit1
DependentUnit2
的声明,则需要添加额外的
使用
引用,并且其声明随后被其他单元使用,因此它们依赖于这些其他单元。如果您可以设计单元来减少接口依赖性,只在
实现
部分使用依赖单元,那么您就不必在其他单元中包含
依赖单元1
依赖单元2
了。但我明白这并不总是可能的


如果你需要在多个单元之间共享代码,最好把代码移到它自己的单元/包。

< P>讽刺的是,你会问这个问题,当一个更好的问题是“为什么C++在2013年还没有模块”。 Delphi的编译单元通常不会拆分为重复的.h和.cpp文件。您可能已经注意到Delphi单元有一个接口和实现部分。这又变成了一个真正的模块系统,编译的.DCU文件与C++/C编译器的.obj文件有很大的不同,因为当遇到“uses UnitX”时,编译器可以非常快速地读取接口区域

最近,苹果的CLANG/LLVM编译器开发人员开始在最新的CLANG/LLVM C和Objective-C编译器中添加真正模块支持的基础。这意味着XCode中的预编译头支持不再是首选的操作方式,因为真正的模块比预编译头更好。你可以说,一个预编译的头系统就像只有一个模块,只有一个模块,当你不能拥有真正的东西,也就是所谓的模块时,你会很乐意拥有一个破旧的乱七八糟的东西。您可能会说,您是一名windows开发人员,您对CLANG/LLVM关心什么?这证明世界正在慢慢放弃预编译,并最终转向模块。C++标准化合作者,以当前的速率工作,最迟将在2113,最新的工作中提供C++工作标准(但不是实现)。 简言之,我们可能会说,您的问题可能是问,如果无马马车将获得允许其加速缓存和快速部署OAT到马动力装置的功能

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

 #include "baseHeader.h"
相当于

 {$I baseHeader.pas}
你可以把任何你喜欢的东西放进那个文件里。甚至是整个接口部分

另一种解决问题的方法是使用条件定义

在主项目文件中

{$DEFINE debugMyApp} 
在您使用的每个单元中

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

那太糟糕了!!!其中一个相关单元是Vcl.Graphics。本单元包含CLRD、clBue和其他颜色的定义。每次我想使用这些颜色定义中的一种,就必须包含Vcl.Graphics,我觉得这很烦人,这基本上在使用DebugService时总是发生…@santiagoIT,这真的没那么烦人。对比一下,它是多么恼人,以重构对依赖的需要,只发现删除它会破坏几十个依赖于仅通过更高级别隐含引用的代码的其他行。现在,必须有人在
dependentHeader.h
中搜索,才能找到它实际上仍然需要的
baseHeader.h
。@santiagoIT:你真的在
调试服务的
界面中使用实际的颜色值,还是只在
实现中使用?记住,每一个都可以有自己的
uses
子句。如果必须在
界面
中使用颜色,但仅使用少数选定颜色,则可以在
界面
中定义自己的枚举,然后在需要时将这些值映射到
实现
中的实际颜色。这将有助于隐藏
Vcl.Graphics
依赖关系。@在DebugService的界面中不使用RemyLebeau颜色。但是,使用DebugService的单元包括其他单元,如ServiceManager(访问DebugService)和Vcl.Graphics,以指定用于调试某些特定对象的颜色