#includes的顺序 [英] Order of #includes
问题描述
我目前正在重新审视C ++应用程序的代码并重新构建
代码，以使其与整体逻辑
设计保持一致。
作为其中的一部分，我正在研究.cpp文件#include标头的方式。我的
问题是这样的：是否有一个标准订单，其中包括应该包含什么价格？
我倾向于#include首先是STL标题，稍后是我自己的标题，但我不能确认这是一个合理的理由。
欢迎任何想法。
Chris Gordon-Smith
伦敦
主页： http://graffiti.virgin.net/c.gordon-smith/
" Chris Gordon-Smith" <我们********* @ my.homepage>写了...我目前正在重新审视C ++应用程序的代码并重新调整代码，以使其与整体逻辑设计保持一致。
作为其中的一部分，我正在寻找.cpp文件#include标头的方式。我的问题是：是否存在标准订单，其中应包括标题？
我们在谈论哪些标题？如果它是标准标题，例如
< iostream>或者< functional>或者< list>，然后不，订单是不重要的。
如果这是你自己的标题，那么我们不知道。虽然从代码的编码方式和整体可维护性的代码来看，如果你的标题之间存在_is_
顺序依赖，那就是A BAD THING（tm） 。
我倾向于首先#include STL标题，然后我自己的标题，但是我不能真的想到这个逻辑上的理由。
没有。
V
" Chris Gordon-Smith <我们********* @ my.homepage>在消息中写道
news：30 ************* @ uni-berlin.de ...我目前正在重新审视代码一个C ++应用程序和重组代码在适当的位置使其与整体逻辑设计保持一致。
作为其中的一部分，我正在研究.cpp文件的方式#include标头。我的问题是：是否有一个标准订单，其中应包含标题？
我倾向于首先#include STL标题，然后我自己的标题，但我
不能真的想到这个的合理理由。
欢迎任何想法。
Chris Gordon-Smith
伦敦
主页： http://graffiti.virgin.net/c .gordon-smith /
我在这个新闻组中学到的很多东西之一就是有一点点b / b
优势首先包括你自己的标题和任何标准库
标题。原因：你自己的标题应该包括他们已经使用的任何库
。否则他们只会在某个包含订单中工作
，正如Victor所说，这是一件坏事。
我不认为这是''这是一个大问题，但首先把你自己的标题放在一个
适度的软件测试，软件不能测试太多。
- -
Cy
http：// home .rochester.rr.com / cyhome /
Cy Edmunds写道：
" Chris Gordon-Smith" ; <我们********* @ my.homepage>在消息中写道
[snip]
作为其中的一部分，我正在寻找.cpp文件#include标头的方式。我的问题是这样的：是否有一个标准订单应该包含什么？
我在这里学到的很多东西之一新闻组认为，首先包含您自己的标题以及稍后包含任何标准的库标题会有一点点优势。原因：你自己的标题应该包括他们已经使用的任何库。否则他们只会按照某个
包含的顺序工作，正如维克多所说，这是一件坏事。
我认为这不是什么大不了的事，而是自己做header首先是一种适度的软件测试，软件不能测试太多。
多亏了这个。我尝试做的一件事是避免从其他头文件中#include头文件
。这意味着我不会编写头文件
依赖于我编写的其他类的头文件。必要时，
我在标题中包含前向声明。例如，我可能有一个标题
像这样： -
class My_Class; //前方声明
class Another_Class
{
public：
void foo（My_Class * bar）; < br $>
}
我相信这种前瞻性声明不适用于STL模板
喜欢< vector>。
由于我没有在头文件中包含标题，我的方法是有一个
标准的库集包括我放在一个名为的文件中
Library_Haeders.h。我项目中的每个源文件都包含
Library_Headers.h。
自昨天发布以来我记得我最初开始使用
当我使用C ++ Builder时这种方法。使用Borland的编译器
以这种方式组织头文件，以便预编译头文件能够正常工作。我不再使用Borland了，但我暂时保留了
''Library_Headers.h''方法。
我认为专业人士和缺点是： -
专业版： -
i）我的#include文件（除了''Library_Headers.h''不要''需要
#include其他#include文件
ii）由于上述原因，我总能告诉你何时查看来源
文件是什么#included。我不需要查看其他文件来查看
他们#include。
Con：
i）由于Library_Headers.h包含了我的应用程序中使用的所有库标题，所以有许多地方包含的内容比
真的需要。
总的来说，我认为优点超过缺点。我认为
Library_Headers.h实际上是提供语言扩展。它提供的STL
元素可用于所有或我的源文件。
这似乎不会严重影响编译时间。在任何情况下，如果我确实开始遇到编译时出现问题，那么为了得到预编译的头文件，可能需要再次使用一套标准库
include />
工作。
-
Chris Gordon-Smith
伦敦
主页： http://graffiti.virgin.net/c.gordon-史密斯/
I am currently revisiting the code of a C++ application and restructuring
the code where appropriate to make it consistent with the overall logical
design.
As part of this, I am looking at the way .cpp files #include headers. My
question is this: Is there a standard order in which heders should be
included?
I tend to #include STL headers first, and my own headers later, but I can''t
really think of a logical justification for this.
Any thoughts welcome.
Chris Gordon-Smith
London
Homepage: http://graffiti.virgin.net/c.gordon-smith/
"Chris Gordon-Smith" <us*********@my.homepage> wrote...I am currently revisiting the code of a C++ application and restructuring
the code where appropriate to make it consistent with the overall logical
design.
As part of this, I am looking at the way .cpp files #include headers. My
question is this: Is there a standard order in which heders should be
included?
Which headers are we talking about? If it''s the standard headers, like
<iostream> or <functional> or <list>, then no, order is unimportant.
If that''s your own headers, then we have no idea. Although from the coding
style and overall maintainability of the code point of view, if there _is_
order dependency between your headers, it''s A BAD THING(tm).
I tend to #include STL headers first, and my own headers later, but I
can''t
really think of a logical justification for this.
There isn''t any.
V
"Chris Gordon-Smith" <us*********@my.homepage> wrote in message
news:30*************@uni-berlin.de...I am currently revisiting the code of a C++ application and restructuring
the code where appropriate to make it consistent with the overall logical
design.
As part of this, I am looking at the way .cpp files #include headers. My
question is this: Is there a standard order in which heders should be
included?
I tend to #include STL headers first, and my own headers later, but I
can''t
really think of a logical justification for this.
Any thoughts welcome.
Chris Gordon-Smith
London
Homepage: http://graffiti.virgin.net/c.gordon-smith/
One of the many things I learned in this newsgroup is that there is a slight
advantage to including your own headers first and any standard library
headers later. Reason: your own header ought to have included any libraries
they use already. Otherwise they will only work in a certain include order
which, as Victor says, is a Bad Thing.
I don''t think it''s a big deal, but putting your own headers first is a
modest sort of software test, and software can''t be tested too much.
--
Cy
http://home.rochester.rr.com/cyhome/
Cy Edmunds wrote:
"Chris Gordon-Smith" <us*********@my.homepage> wrote in message [snip]
As part of this, I am looking at the way .cpp files #include headers. My
question is this: Is there a standard order in which heders should be
included?
One of the many things I learned in this newsgroup is that there is a
slight advantage to including your own headers first and any standard
library headers later. Reason: your own header ought to have included any
libraries they use already. Otherwise they will only work in a certain
include order which, as Victor says, is a Bad Thing.
I don''t think it''s a big deal, but putting your own headers first is a
modest sort of software test, and software can''t be tested too much.
Thanks for this. One thing I try to do is to avoid #including header files
from within other header files. This means that I don''t write header files
that rely on header files for other classes that I write. Where necessary,
I include forward declarations in my headers. Eg, I might have a header
like this:-
class My_Class; // Forward declaration
class Another_Class
{
public:
void foo(My_Class* bar);
}
I believe that this kind forward declaration doesn''t work with STL templates
like <vector>.
Since I don''t include headers in my header files, my approach is to have a
standard set of library includes that I put in a file called
Library_Haeders.h. Every one of the source files in my project includes
Library_Headers.h.
I''ve remembered since my posting yesterday that I originally started using
this approach when I was using C++ Builder. With Borland''s compiler its
necessary to organise headers in this way in order for precompiled headers
to work properly. I no longer use Borland, but I''m keeping the
''Library_Headers.h'' approach for the moment.
I think that the pros and cons are:-
Pro:-
i) My #include files (except for ''Library_Headers.h'' don''t need to
#include other #include files
ii) As a result of the above, I can always tell when looking at a source
file what is #included. I don''t need to look in other files to see what
they #include.
Con:
i) Since Library_Headers.h includes all of the library headers that are
used in my application, there are many places where more is included than
is really needed.
On balance, I think that the pros outweigh the cons. I regard
Library_Headers.h as, in effect, providing a language extension. The STL
elements it provides are available to all or my source files.
This doesn''t seem to be affecting compile times seriously. In any case, if I
did start getting compile time problems, having a standard set of library
includes might become necessary again in order to get pre-compiled headers
working.
--
Chris Gordon-Smith
London
Homepage: http://graffiti.virgin.net/c.gordon-smith/
这篇关于#includes的顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
