头文件和接口再次 [英] Header Files and Interfaces Yet Again
问题描述
过去，关于
头文件在C ++中的作用已经进行了冗长的讨论。人们一直非常喜欢头文件
作为实现的接口。我理解
的目标。这个例子可能代表了一个需要一点点b / b
重构的界面，但它是为了展示我理解的基本思想。
http://developer.kde.org/documentati .. .8h-source.html
在不同的背景下出现了什么让我重新考虑我的
界面概念是否被其他人共享。它也让我意识到
是理解其含义的另一种方式。通过使用该术语可以实现接口的界面。
作为一个激励性的例子，考虑硬件接口的概念。
是一组用于连接和与
界面交互的规则。通常这样的界面要求用户事先知道如何指定它。例如，很可能是包含接口规范的
技术手册。有可能，
但接口自我描述的可能性较小。也就是说，
用户可以通过查询界面来获取其规格。
在软件中有两种接口的实例。直到最近我才把b $ b从未认为头文件可能会作为这两种界面的前者使用。也就是说，它可能不是自我描述的。以
为例，一个头文件几乎没有任何内容，只有
预处理指令有条件地分支到包含
声明的另一个文件，也许是另一个间接层。
你认为这样描述的实现是代表一个接口吗？
-
STH
哈顿定律：只有一个不可侵犯的法律
KDevelop： http://www.kdevelop.org SuSE： http：/ /www.suse.com
Mozilla： http：// www.mozilla.org
Steven T. Hatton写道：
在过去，关于
头文件在C ++中的作用已经进行了冗长的讨论。人们一直非常喜欢头文件
作为实现的接口。我理解
目标。这个例子可能代表了一个需要进行一些重构的界面，但是它可以证明我理解它的基本思想。
http://developer.kde.org/documentati...8h-source .html
在不同的背景下出现了一些东西让我重新考虑是否
我的界面概念是否被其他人共享。它也让我意识到
是理解其含义的另一种方式。通过使用该术语可以实现界面的过多类别。
作为一个激励性的例子，考虑硬件接口的概念。
有一组用于连接和与
界面交互的规则。通常这样的界面要求用户事先知道如何指定它。例如，很可能是
包含接口规范的技术手册。这是可能的，但接口自我描述的可能性较小。也就是说，
用户可以通过查询界面来获得
规格。
在软件中有两种接口的实例。直到
最近我才从未考虑过头文件可能会作为这两种界面的前者。也就是说，它可能不是自我描述的。以
为例，一个头文件实际上只包含
预处理指令，有条件地分支到包含声明的另一个文件
，也许还有另一层间接。
你认为这样描述的实现是代表
接口吗？
这真的很重要对你来说，你的b $ b b研究员的语言直觉是否是这个界面？好吧，对于它的价值，
我会说*它是*一个界面。毕竟，这是我获取某些图书馆提供的电力的手段。然而，从我的观点来看，
我想要一个独立的描述，当我写作时，我的客户代码可以显示为什么？
#include< foo.h>
这个描述反过来可能会通过一个看起来像*的文件给我*
它是由预处理器实际替换的头文件foo.h。在
的事实上，对于我自己的模板库文件，我通常会写一个假的标题
文件，其中包含所有标识符的注释声明
header应该提供给客户端代码。这是一个方便的方法，以简洁的方式提醒自己，编译器将读取的不可思议的实际标题文件应该是什么。但是，我的假标题（供我阅读）和标题文件
（放在我的编译器的包含路径中）同意，没有
假设。例如，
包含的头文件可能会引入不应该在客户端代码中出现的
的标识符，但仅供内部使用。那些，我不会在假的标题中包含
。
现在，这就是我正在做的跟踪我的小型库。但是它可能会为您正在考虑的IDE提供一个想法（我已经接下来讨论了一下这个讨论）。也许，IDE不应该使用与编译器相同的包含路径
。它将从
虚假的haeders中获取知识，最好由图书馆供应商提供，作为他们的b
文档的一部分。 （就STL而言，不需要不同的供应商来运送那些假的标题，因为他们都必须要b / b
。因此IDE可能会在它的
包含路径中加载这些知识。）但是，如果图书馆供应商不那么倾向，那么有人可以自愿编写标题并独立编写标题。我会假设
，如果IDE的想法得以实现，这个需求将变得不那么频繁了
时间。
最好的问候
Kai-Uwe
PS。我的一个朋友告诉我，有两种问题：工程问题和政治问题。不同的是，工程问题有时会产生解决方案。作为必然结果，如果面临一些困难，最好找到一个观点，它看起来像是一个工程问题。
Kai-Uwe Bux写道：
对你来说，你的语言直觉是否真的很重要
研究员是，这是或不是一个界面？
事实证明，我发现没有对这个
意味着什么会导致重大沟通问题的良好共识。
好吧，对于它的价值，我会说*它是*一个界面。毕竟，这是我获取某些图书馆提供的电力的手段。
考虑到我之前的陈述，我很难不同意。但是它
肯定不是我在concjunction中使用的接口概念
带有头文件的
。
从我的角度来看，<但是，当我写作时，我想要一个关于我的客户代码可见的内容的独立描述
#include< foo.h>
反过来，这个描述可能是由一个看起来像*的文件给我的，好像它是由预处理器实际替换的头文件foo.h。
这正是我对这种情况的回应。
现在，这就是我正在做的跟踪我的小型图书馆的事情。但是它可能为您正在考虑的IDE提供了一个想法（我已经进行了一些讨论）。也许，IDE不应该使用与编译器相同的包含路径。它将从伪造的haeders中获取知识，理想情况下由图书馆供应商提供，作为其文档的一部分。 （就STL而言，不需要不同的供应商来运送那些假的标题，因为他们都必须同意。
至少有两个潜在的问题。首先，如果
实现者与标准中提供的标题不完全匹配，
我将不得不调整我的标题以匹配实现。其次，标准库的一个实现的
实现者（STL是一个
非正式子集，我相信）告诉我有
标准没有完全指定界面的地方，还有一些其他问题
涉及循环依赖。我也相信可能有些地方
标准对于正在实施的事情非常具体。
定义。例如：
命名空间std {
模板< class charT，class traits = char_traits< charT>，
class Allocat或= allocator< charT> >
class basic_string {
public：
// types：
typedef traits traits_type;
typedef typename traits :: char_type value_type;
typedef分配器allocator_type;
typedef typename Allocator :: size_type size_type;
typedef typename Allocator :: difference_type difference_type;
typedef typename Allocator :: reference reference;
typedef typename Allocator :: const_reference const_reference;
typedef typename Allocator ::指针指针;
typedef typename Allocator :: const_pointer const_pointer;
typedef implementation defined iterator; //参见
lib.container.requirements
typedef实现定义的const_iterator; //请参阅
lib.container.requirements
typedef std :: reverse_iterator< iterator> reverse_iterator;
typedef std :: reverse_iterator< const_iterator> const_reverse_iterator;
static const size_type npos = -1;
// lib.string.cons因此IDE可以在其中预先加载该知识/>包括路径。）但是，如果图书馆供应商不那么倾向，那么其他人可以自愿并独立编写标题。我认为如果IDE的想法得以实现，那么这个需求会随着时间的推移变得不那么频繁。
我真的不是确定是什么让你的假标题假。 Stroustrup
表明您的方法适用于某些情况。当用户的代码被编译时，他们是否可以访问
？
我希望我正在处理的人会从震惊我的
表明标准标题应该提供这样的表示，并且
将与我合作确定如何进行必要的
修改它们出现在标准中的标题。
-
STH
哈顿定律：只有一个不可侵犯法律
KDevelop： http://www.kdevelop.org SuSE： http://www.suse.com
Mozilla： http://www.mozilla.org
Steven T. Hatton写道：
Kai-Uwe Bux写道：这个描述依次为migh如果*它是由
预处理器实际替换的头文件foo.h，则给我一个看起来像*
的文件。
这正是我对这种情况的回应。 br />现在，这就是我正在做的跟踪我的小型库。但是它可能为您正在考虑的IDE提供了一个想法（我已经进行了一些讨论）。也许，IDE不应该使用与编译器相同的包含路径。它将从伪造的haeders中获取知识，理想情况下由图书馆供应商提供，作为其文档的一部分。 （就STL而言，不需要供不同供应商运送那些假的标题，因为他们都会同意这一点。
至少有两个潜在的问题。首先，如果
实现者与
标准中提供的标题不完全匹配，我将不得不调整我的标题以匹配实现。
嗯，如果实施与标准不符，我认为你有一个令人信服的说服供应商应该解决的问题。但是那将是一个我怀疑的政治方法。所以，我承认可能会有问题。但是，我的理解是编译器/库是
朝着标准趋同。从去年我遇到的g ++
开始，收敛速度非常快。每个新版本几乎都是
打破了我的代码。（告诉你一些我的同事ding，我
猜测:-)
其次，标准库的一个实现的实现者（STL
是非正式的子集，我相信）已经告诉我有些地方
标准没有完全指定界面，还有其他一些涉及循环依赖的问题。
在您经历过的所有
讨论之后，您可能对这方面有了更好的理解。我想知道，这些
循环依赖是什么。也许只是标准将相同的
标识符放入几个标题中，这意味着这些标识符应该通过包含标题A以及包含标题B而变得可见。一个
的实现者可能不得不打破这个并做出决定。或者供应商
可能会采用一些宏观魔法来解决这个问题。一个例子可能是，
我也不知道是否是这种情况，标识符如std :: cout。这是一个静态对象，最多可以声明一次。如果几个
标题提供了对这个标识符的访问权限，它仍然无法在
中定义所有这些标识符。
For，what我称之为假标题那不是问题。只需
记录两者中的标识符，因为其中任何一个都将使客户端代码可访问的标识符为
。假标题，因为我使用它们，只是
提供有关哪些标识符由某个
include指令可见的信息。这就是我硬盘上的全部目的。
我应该停止推测循环依赖的含义。因为我必须承认，我不是在深入研究这个问题，而是要了解
专家可能提到的内容。在这一点上，对于这样一个问题的具体例子肯定会有所帮助。
我也相信可能有些地方
标准关于正在实施的事情是非常具体的定义。例如：
namespace std {
template< class charT，class traits = char_traits< charT>，
class Allocator = allocator< charT> >
class basic_string {
public：
// types：
typedef traits traits_type;
typedef typename traits :: char_type value_type;
typedef Allocator allocator_type ;
typedef typename Allocator :: size_type size_type;
typedef typename Allocator :: difference_type difference_type;
typedef typename Allocator :: reference reference;
typedef typename Allocator :: const_reference const_reference;
typedef typename Allocator ::指针指针;
typedef typename Allocator :: const_pointer const_pointer;
typedef实现定义的迭代器; //参见
lib.container.requirements
typedef实现定义的const_iterator; //参见
lib.container.requirements
typedef std :: reverse_iterator< iterator> reverse_iterator;
typedef std :: reverse_iterator< const_iterator> const_reverse_iterator;
static const size_type npos = -1;
// lib.string.cons
我假设实现定义的typedef很烦您？现在，我想知道如果用户（或聪明的
IDE）知道或关心这些类型是什么，那么它是否真的非常好。当然，依靠
类型就是特定实现中的类型将使您的
代码不可移植。我不想知道这个，也许我会不希望我的IDE关心它。因此，我建议引入
a特殊关键字implementsmetation_defined用于伪标题，
让每个人（包括IDE）明白你应该*不*
知道/关心这个。任何*真正需要*知道的程序员都会自行查找
。但是，这可能是一件好事。
此外，还有一个额外的问题，即实现定义
类型可能不是语言可表达的类型完全是C ++的意思。
它可能只是一个占位符，可以在编译器中进行一些魔术。
坚持认为那些类型*必须*是真实的可能来自在某些情况下表现为b
罚款。但是我再次开始猜测，并且我没有那么多关于编译器设计的评估，以确定这是否真的是一个
问题。
我我真的不确定是什么让你的伪造标题假。 Stroustrup
建议您的方法适用于某些情况。是否在编译用户代码时访问它们？
这正是使他们伪造的原因：编译器根本没有看到
。它们完全是我自己的检查。看，我的C ++编码
风格仍然不是很成熟，我实际上更愿意不申报，而是立即定义
（有点像Oberon风格）。现在，这使得界面难以理解，因为代码阻碍了。因此，我创建了第二个文件
，所有定义都转换为声明并删除了所有代码。
只保留描述例程所做的注释。还有一些
内部的东西，比如必须放在
命名空间级别并且无法隐藏的私有字段或帮助程序类，如果
它们应该是客户端代码的限制。这个文件，假的
标题，仅适用于我的眼睛！
所以假的标题不会放在我的编译器的包含路径中但是在
doc /目录。当然有一个问题是保持标题
文件和假标题同步。但由于我的代码库不是很大，
我可以逃脱它。
我的编译器没有看到假的标题还有一个额外的
优势：他们可以稍微松散地遵循C ++语法。因此，关键字
就像implementation_defined一样或off_limits，这将导致编译器
翘起，不一定是用户（或IDE）的问题。对于实际的头文件，伪标题*必须*可用作可能的实现
，这不是公开的。它们服务于不同的目的，它们可以满足不同的观众需求：我作为自己代码的客户端（或者是一个能够确保智取我的b / b的IDE）。我的假标题没有解决编译器，实际头文件的读者是
。
我希望我正在处理的人会恢复从我的震惊中建议标准标题应该提供这样的表示，并且
将与我合作确定如何对标题中出现的标题进行必要的修改。
我认为人们认为你认为编译器解析的头文件应该或多或少看起来像是什么我们可以从
中猜出标准中给出的这些标题的描述。我是什么？b $ b建议可能没有必要设计一个IDE，即编译器和IDE正在解析相同的文件。但话说回来，我还没有真正考虑过设计IDE时遇到的问题。如果它是b / b
是你的工程意见，IDE和编译器需要访问
相同的信息，你可能是对的。当然，我不是那个在这个帐户上证明你错了的人。
最好的问候
Kai-Uwe
In the past there have been lengthy discussiions regarding the role of
header files in C++. People have been very adamat about header files
serving as in interface to the implementation. I do understand the
objective. This example may represent an interface in need of a bit of
refactoring, but it goes to demonstrate the basic idea as I understand it.
http://developer.kde.org/documentati...8h-source.html
Something came up in a different context which made me reconsider whether my
concept of interface is shared by others. It also made me realize there is
an alternative way of understanding the meaning. There are too catagories
of interface which could be intended by the use of the term.
As a motivating example consider the concept of a hardware interface. There
is a certain set of rules for connecting to, and interacting with the
interface. Usually such an interface requires the user to have prior
knowledge of how it is specified. For example, there will most likely be a
technical manual containing the interface specification. It is possible,
but less likely that an interface will be self-describing. That is, the
user would have a means of querying the interface to get its specification.
In software there are instances of both kind of interface. Until recently I
had never considered that a header file might serve as the former of these
two types of interface. That is, it might not be self-describing. Take as
an example, a header file which consists of virtually nothing but
preprocessing directives conditionally branching to another file containing
declarations and perhaps another layer of indirection.
Do you consider the implementation thus described to represent an interface?
--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Steven T. Hatton wrote:
In the past there have been lengthy discussiions regarding the role of
header files in C++. People have been very adamat about header files
serving as in interface to the implementation. I do understand the
objective. This example may represent an interface in need of a bit of
refactoring, but it goes to demonstrate the basic idea as I understand it.
http://developer.kde.org/documentati...8h-source.html
Something came up in a different context which made me reconsider whether my concept of interface is shared by others. It also made me realize there is an alternative way of understanding the meaning. There are too catagories
of interface which could be intended by the use of the term.
As a motivating example consider the concept of a hardware interface. There is a certain set of rules for connecting to, and interacting with the
interface. Usually such an interface requires the user to have prior
knowledge of how it is specified. For example, there will most likely be a technical manual containing the interface specification. It is possible,
but less likely that an interface will be self-describing. That is, the
user would have a means of querying the interface to get its specification.
In software there are instances of both kind of interface. Until recently I had never considered that a header file might serve as the former of these
two types of interface. That is, it might not be self-describing. Take as an example, a header file which consists of virtually nothing but
preprocessing directives conditionally branching to another file containing declarations and perhaps another layer of indirection.
Do you consider the implementation thus described to represent an
interface?
Hi,
is it really important to you whether the linguistic intuitions of your
fellows are that this is or is not an interface? Well, for what it''s worth,
I would say it *is* an interface. After all, it is the means by which I
access the power provided by some library. From my point of view, however,
I will want an independent description of what acutally becomes visible to
my client code when I write
#include <foo.h>
This description in turn might be given to me by a file that looks *as if*
it was the header file foo.h actually substituted by the preprocessor. In
fact, for my own template library files, I usually write such a fake header
file containing the commented declarations for all identifiers that this
header is supposed to provide to client code. This is a convenient means of
reminding myself in a concise way of what the inscrutable actual header
file that the compiler will read is supposed to do. There is, however, no
presumption that my fake header (for me to read) and the header file
(placed in the include path of my compiler) agree. For instance, the
included header file might introduce identifiers that are not supposed to
occur in the client code but are for internal use only. Those, I would not
include within the fake header.
Now, this is just what I am doing to keep track of my small library. But it
might provide an idea for the IDE that you are thinking about (I have
followed a little bit of this discussion). Maybe, the IDE should not use
the same include path as the compiler. It would derive its knowledge from
fake haeders, ideally provided by library vendors as part of their
documentation. (As far as the STL is concerned, there would be no need for
different vendors to ship those fake headers as they would all have to
agree anyway. Thus the IDE could come preloaded with that knowledge in its
include path.) If, however, a library vendor is not so inclined, someone
else could volunteer and write the header independently. I would assume
that if the IDE idea catches on, this need will become less frequent with
time.
Best regards
Kai-Uwe
PS. A friend of mine taught me that there are two kinds of problems:
engineering problems and political problems. The difference is that
engineering problems sometimes do have solutions. As a corollary, if facing
some difficulty, it is better to find a point of view from which it appears
as an engineering problem.
Kai-Uwe Bux wrote:
is it really important to you whether the linguistic intuitions of your
fellows are that this is or is not an interface?
As it turns out, I''ve found not having a good common definion of what this
means can lead to significant communication problems.
Well, for what it''s
worth, I would say it *is* an interface. After all, it is the means by
which I access the power provided by some library.
Considering my previous statements, I''d be hard pressed to disagree. But it
is certainly not a concept of interface that I have used in concjunction
with header files.
From my point of view,
however, I will want an independent description of what acutally becomes
visible to my client code when I write
#include <foo.h>
This description in turn might be given to me by a file that looks *as if*
it was the header file foo.h actually substituted by the preprocessor.
This is exactly my response to the situation.
Now, this is just what I am doing to keep track of my small library. But
it might provide an idea for the IDE that you are thinking about (I have
followed a little bit of this discussion). Maybe, the IDE should not use
the same include path as the compiler. It would derive its knowledge from
fake haeders, ideally provided by library vendors as part of their
documentation. (As far as the STL is concerned, there would be no need for
different vendors to ship those fake headers as they would all have to
agree anyway.
There are at least two potential problems with that. First, if the
implementor doesn''t exactly match the headers as presented in the Standard,
I will have to adjust my headers to match the implementation. Second, the
implementors of one implementation of the Standard Library(STL is an
informal subset, I believe) have told me there are places where the
standard does not completely specify the interface, and some other problems
involving circular dependencies. I also believe there may be some places
where the standard is very specific about things being implementation
defined. For example:
namespace std {
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_string {
public:
// types:
typedef traits traits_type;
typedef typename traits::char_type value_type;
typedef Allocator allocator_type;
typedef typename Allocator::size_type size_type;
typedef typename Allocator::difference_type difference_type;
typedef typename Allocator::reference reference;
typedef typename Allocator::const_reference const_reference;
typedef typename Allocator::pointer pointer;
typedef typename Allocator::const_pointer const_pointer;
typedef implementation defined iterator; // See
lib.container.requirements
typedef implementation defined const_iterator; // See
lib.container.requirements
typedef std::reverse_iterator<iterator> reverse_iterator;
typedef std::reverse_iterator<const_iterator> const_reverse_iterator;
static const size_type npos = -1;
// lib.string.cons Thus the IDE could come preloaded with that knowledge in its
include path.) If, however, a library vendor is not so inclined, someone
else could volunteer and write the header independently. I would assume
that if the IDE idea catches on, this need will become less frequent with
time.
I''m really not sure what makes your "fake" headers "fake". Stroustrup
suggest there are situations in which your approach is applicable. Are they
accessed when the user''s code is compiled?
I''m hoping the people I''m dealing with will recover from the shock of my
suggesting the Standard Headers should provide such a representation, and
will cooperate with me in determining how to make the necessary
modifications to the Headers as they appear in the Standard.
--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Steven T. Hatton wrote:
Kai-Uwe Bux wrote:This description in turn might be given to me by a file that looks *as
if* it was the header file foo.h actually substituted by the
preprocessor.
This is exactly my response to the situation.Now, this is just what I am doing to keep track of my small library. But
it might provide an idea for the IDE that you are thinking about (I have
followed a little bit of this discussion). Maybe, the IDE should not use
the same include path as the compiler. It would derive its knowledge from
fake haeders, ideally provided by library vendors as part of their
documentation. (As far as the STL is concerned, there would be no need
for different vendors to ship those fake headers as they would all have
to agree anyway.
There are at least two potential problems with that. First, if the
implementor doesn''t exactly match the headers as presented in the
Standard, I will have to adjust my headers to match the implementation.
Hm, if the implementation does not match the standard, I think you have a
convincing case that the vendor should fix this. But that would be a
political approach of which I am sceptical. So, I concede that there might
be problems. However, my understanding is that compilers/libraries are
converging towards the standard. From what I was experiencing with g++
during the last year, convergence happens at a remarkable speed. Almost
every new release breaks my code. (Tells you something about my coding, I
guess :-)
Second, the implementors of one implementation of the Standard Library(STL
is an informal subset, I believe) have told me there are places where the
standard does not completely specify the interface, and some other
problems involving circular dependencies.
You probably have a way better understanding of this after all the
discussion that you have been through. I would like to know, what these
circular dependencies are. Maybe it is just that the standard puts the same
identifier into several headers, meaning that these identifiers should
become visible by including header A as well as by including header B. An
implementor might have to break this and make a decission. Or the vendor
might resort to some macro magic to deal with this. An example could be,
also I do not know if this is the case, identifiers like std::cout. This is
a static object that can certainly be declared at most once. If several
headers provide access to this identifier, it still cannot be defined in
all of them.
For, what I have called "fake headers" that would not be a problem. Just
document the identifier in both of them as including either one will make
the identifier accessible to client code. Fake headers, as I use them, just
provide information about which identifiers become visible by a certain
include directive. That is their whole purpose on my hard disc.
I should stop speculating about the meaning of "circular dependencies" as I
have to admit that I am not as deeply into this issue as to understand what
experts might have refered to. At this point, it would certainly be helpful
to have a concrete example of such a problem.
I also believe there may be some places
where the standard is very specific about things being implementation
defined. For example:
namespace std {
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_string {
public:
// types:
typedef traits traits_type;
typedef typename traits::char_type value_type;
typedef Allocator allocator_type;
typedef typename Allocator::size_type size_type;
typedef typename Allocator::difference_type difference_type;
typedef typename Allocator::reference reference;
typedef typename Allocator::const_reference const_reference;
typedef typename Allocator::pointer pointer;
typedef typename Allocator::const_pointer const_pointer;
typedef implementation defined iterator; // See
lib.container.requirements
typedef implementation defined const_iterator; // See
lib.container.requirements
typedef std::reverse_iterator<iterator> reverse_iterator;
typedef std::reverse_iterator<const_iterator> const_reverse_iterator;
static const size_type npos = -1;
// lib.string.cons
I assume that the implemetation defined typedefs are bothering you? Now, I
would like to know if it was really all that good if the user (or a smart
IDE) would know or care about what these types are. Certainly, relying on
that type being what it is in a particular implemetation will make your
code non-portable. I would not want to know about this, and maybe I would
not want my IDE to care about it either. Thus, I would suggest to introduce
a special keyword implemetation_defined for the use in fake headers that
makes it clear to everybody (including IDEs) that you are supposed *not* to
know/care about this. Any programmer, who *really needs* to know will have
to find out by himself. But, that might be a good thing.
Besides, there is the additional problem that an implementation defined
type may not be a type expressible with the linguistic means of C++ at all.
It could be just a placeholder for some magic going on within the compiler.
Insisting that those types *must* be for real might come with a performance
penalty in some situations. But I start speculating again, and I do not
that much about compiler design as to asses whether this is really a
problem.
I''m really not sure what makes your "fake" headers "fake". Stroustrup
suggest there are situations in which your approach is applicable. Are
they accessed when the user''s code is compiled?
That is precisely what makes them "fake": the compiler does not get to see
them at all. They are entirely for my own inspection. See, my C++ coding
style is still not very mature, and I actually prefer to not declare but to
define right away (sort of the Oberon style). Now, this makes the interface
hard to comprehend as code gets in the way. Thus, I create a second file
with all definitions turned into declarations and all the code removed.
Only the comments describing what the routines do are preserved. Also some
internal stuff, like private fields or helper classes that had to be put in
namespace level and could not be hidden are left out of the fake headers if
they are supposed to be off limits for client code. This file, the fake
header, is for my eyes only!
So the fake header is not put in the include path for my compiler but in a
doc/ directory. Of course there is a certain problem of keeping the header
file and the fake header in sync. But since my code base is not very large,
I can get away with it.
That my compiler does not look at the fake headers has an additional
advantage: they could follow the C++ syntax a little loosely. Thus keywords
like "implementation_defined" or "off_limits", which would cause a compiler
to hick up, need not be a problem for the user (or an IDE). It is not
axiomatic that fake headers *must* be usable as a possible implementation
for the actual header file. They serve a different purpose, they address a
different audience: me as a client of my own code (or an IDE that will
surely outsmart me). My fake headers do not address the compiler, which is
the audience for the actual header files.
I''m hoping the people I''m dealing with will recover from the shock of my
suggesting the Standard Headers should provide such a representation, and
will cooperate with me in determining how to make the necessary
modifications to the Headers as they appear in the Standard.
I think people take it to be your opinion that the header files as parsed
by the compiler ought to look more or less like what one would guess from
the description of these headers given in the standard. What I am
suggesting is that it might not be necessary for engineering an IDE that
the compiler and the IDE are parsing the same files. But then again, I have
not really thought about the problems one faces in designing an IDE. If it
is your informed engineering opinion that IDE and compiler need to access
identical information, you may be right. Certainly, I am not the one to
prove you wrong on this account.
Best regards
Kai-Uwe
这篇关于头文件和接口再次的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
