blocks|key|3255594|text|性能将会提高，因为头文件中的实现是隐式内联的。正如你提到的，你的函数很小，内联操作对你很有好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3255595|你所说的编译器，除了头文件或.cpp文件中的代码之间的内联之外，true.There对于编译器来说也没有区别。|offset|length|style|CODE|3255596|entityMap^0|0|E|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There will be an increase in performance because implementation in header files are implicitly inlined. As you mentioned your functions are small, inline operation will be so beneficial for you IMHO.

What you say about compiler is also true.There is no difference for compiler&mdash;other than inlining&mdash;between code in header file or <code>.cpp</code> file.

blocks|key|3468739|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3468740|如果你的函数这么简单，就让它们内联，然后你就必须把它们放在头文件中。除此之外，任何约定都只是-+conventions.|ordered-list-item|3468741|Yes，编译器在遇到#include语句的地方展开头文件。|3468742|3468743|entityMap^0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|I|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|J|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|K|7|@]|8|@]|9|$]]|$1|F|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|M|7|@]|8|@]|9|$]]]|H|$]]

<ol>
<li>If your functions are that simple, make them inline, and you'll have to stick them in the header file anyway. Other than that, any conventions are just that - conventions.</li>
<li>Yes, the compiler does expand the header file where it encounters the #include statements.</li>
</ol>

blocks|key|3255619|text|如果函数很小(您经常更改它的可能性很低)，并且如果函数可以放入标头而不包含大量其他标头(因为您的函数依赖于它们)，那么这样做是完全有效的。如果您将它们声明为外部内联，则编译器需要为每个编译单元提供相同的地址：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3255620|headera.h|3255621|inline+string+method()+{
++++return+something;
}|code-block|syntax|javascript|3255622|如果成员函数是在其类中定义的，则它们是隐式内联函数。同样的事情也适用于它们:如果它们可以毫不费力地放入头部，那么您确实可以这样做。|3255623|因为函数的代码被放在头中并且是可见的，所以编译器能够内联对它们的调用，也就是说，将函数的代码直接放在调用位置(不是因为你在它之前放了内联，而是更多的是因为编译器决定这样做。只使用内联是对编译器的一个提示)。这可以提高性能，因为编译器现在可以看到参数与函数本地变量匹配的地方，以及参数不会相互混淆的地方-最后但并非最不重要的是，不再需要函数帧分配。|3255624|3255625|我的理解是，当编译完成时，编译器将展开头文件并将其放在包含它的地方。对吗？|blockquote|3255626|3255627|3255628|是的，这是正确的。该函数将在包含其标头的每个位置定义。编译器只关心将它的一个实例放入结果程序中，而不是删除其他实例。|3255629|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|12|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|15|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|V|$]]

If the function is small (the chance you would change it often is low), and if the function can be put into the header without including myriads of other headers (because your function depends on them), it is perfectly valid to do so. If you declare them extern inline, then the compiler is required to give it the same address for every compilation unit:

headera.h:

<pre><code>inline string method() {
 return something;
}
</code></pre>

Member functions are implicit inline provided they are defined inside their class. The same stuff is true for them true: If they can be put into the header without hassle, you can indeed do so. 

Because the code of the function is put into the header and visible, the compiler is able to inline calls to them, that is, putting code of the function directly at the call site (not so much because you put inline before it, but more because the compiler decides that way, though. Putting inline only is a hint to the compiler regarding that). That can result in a performance improvement, because the compiler now sees where arguments match variables local to the function, and where argument doesn't alias each other - and last but not least, function frame allocation isn't needed anymore.

<blockquote>
 My understanding is when the compilation is done, compiler will expand the header file and place it where it is included. Is that correct?
</blockquote>

Yes, that is correct. The function will be defined in every place where you include its header. The compiler will care about putting only one instance of it into the resulting program, by eliminating the others.

blocks|key|414264|text|这取决于适用于您的情况的编码标准，但是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|414265|没有循环和其他任何东西的小函数应该内联以获得更好的性能(但稍微大一点的代码-对于一些受约束的或嵌入式应用程序很重要)。|414266|如果你将函数体放在头中，那么默认情况下你会把它放在内联(D)中(这在速度上是一件好事)。|414267|在编译器创建目标文件之前，会调用预处理器(对于gcc来说是-E选项)，并将结果发送给编译器，由编译器在代码之外创建对象。|414268|所以更简短的答案是：|414269|--在header中声明函数有利于速度(但不利于空间)+--|414270|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

It depends on the coding standards that apply in your case but:

Small functions without loops and anything else should be inlined for better performance (but slightly larger code - important for some constrained or embedded applications).

If you have the body of the function in the header you will have it by default inline(d) (which is a good thing when it comes to speed).

Before the object file is created by the compiler the preprocessor is called (-E option for gcc) and the result is sent to the compiler which creates the object out of code.

So the shorter answer is:

-- Declaring functions in header is good for speed (but not for space) --

blocks|key|414327|text|根据您的编译器及其设置，它可能会执行以下任一操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|414328|414329|它可以忽略inline关键字(它只是对编译器的一个提示，而不是一个命令)，并生成独立的函数。如果你的函数超过了依赖于编译器的复杂度阈值，它可能会这样做。例如，太多的嵌套循环。|unordered-list-item|414330|它可能会决定你的独立函数是一个很好的内联扩展候选者。|414331|414332|在许多情况下，编译器可以比您更好地确定函数是否应该内联，因此没有必要事后再猜测它。当一个类有许多小函数时，我喜欢使用隐式内联，因为在类中有实现是很方便的。对于较大的函数，这并不能很好地工作。|414333|另一件要记住的事情是，如果你要导出一个DLL/共享库中的类(+IMHO不是一个好主意，但人们无论如何都会这么做)，你需要非常小心地使用内联函数。如果构建DLL的编译器决定应该内联一个函数，那么您就有两个潜在的问题：|414334|414335|使用动态链接库生成程序的编译器可能会决定不内联函数，这样它将生成对不存在的函数的符号引用，并且不会加载动态链接库。|ordered-list-item|414336|如果更新动态链接库并更改内联函数，客户端程序仍将使用该函数的旧版本，因为该函数已内联到客户端代码中。|414337|414338|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|Y|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|14|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|U|$]]

Depending on your compiler and it's settings it may do any of the following:

<ul>
<li>It may ignore the inline keyword (it
is just a hint to the compiler, not a
command) and generate stand-alone
functions. It may do this if your
functions exceed a compiler-dependent
complexity threshold. e.g. too many
nested loops.</li>
<li>It may decide than your stand-alone
function is a good candidate for
inline expansion.</li>
</ul>

In many cases, the compiler is in a much better position to determine if a function should be inlined than you are, so there is no point in second-guessing it. I like to use implicit inlining when a class has many small functions only because it's convenient to have the implementation right there in the class. This doesn't work so well for larger functions.

The other thing to keep in mind is that if you are exporting a class in a DLL/shared library (not a good idea IMHO, but people do it anyway) you need to be really careful with inline functions. If the compiler that built the DLL decides a function should be inlined you have a couple of potential problems:

<ol>
<li>The compiler building the program
using the DLL might decide to not
inline the function so it will
generate a symbol reference to a
function that doesn't exist and the
DLL will not load.</li>
<li>If you update the DLL and change the
inlined function, the client program
will still be using the old version
of that function since the function
got inlined into the client code.</li>
</ol>

blocks|key|411108|text|你应该使用内联函数。请阅读此Inline+Functions以更好地了解所涉及的权衡。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|411109|entityMap|0|LINK|mutability|MUTABLE|url|http://www.parashift.com/c%2B%2B-faq-lite/inline-functions.html^0|E|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You should use inline functions. Read this <a href="http://www.parashift.com/c++-faq-lite/inline-functions.html" rel="nofollow noreferrer">Inline Functions</a> for a better understanding and the tradeoffs involved.

blocks|key|414600|text|如果你这样做了，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|414601|+C%2B%2B不会抱怨，但一般来说，你不应该这样做。|blockquote|414602|414603|当#include一个文件时，被包含文件的全部内容将被插入到包含点。这意味着您放在头文件中的任何定义都会复制到包含该头文件的每个文件中。|414604|对于小型项目，这不太可能是一个大问题。但对于较大的项目，这可能会使编译花费更长的时间(因为每次遇到相同的代码都会重新编译)，并且可能会显著增加可执行文件的大小。如果对代码文件中的定义进行了更改，则只需要重新编译该.cpp文件。如果对头文件中的定义进行了更改，则需要重新编译包含该头文件的每个代码文件。一个小小的改变可能会导致你不得不重新编译整个项目！|414605|有时，对于不太可能改变的琐碎函数会有例外(例如，函数定义为一行)。|414606|414607|来源：http://archive.li/ACYlo+(关于learncpp.com的第1.9章的前一个版本)|offset|length|414608|entityMap|0|LINK|mutability|MUTABLE|url|http://archive.li/ACYlo^0|0|0|0|0|0|0|0|3|N|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@$O|16|P|17|1|18]]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

<blockquote>
C++ won’t complain if you do, but generally speaking, you shouldn’t.
when you #include a file, the entire content of the included file is inserted at the point of inclusion. This means that any definitions you put in your header get copied into every file that includes that header.
For small projects, this isn’t likely to be much of an issue. But for larger projects, this can make things take much longer to compile (as the same code gets recompiled each time it is encountered) and could significantly bloat the size of your executable. If you make a change to a definition in a code file, only that .cpp file needs to be recompiled. If you make a change to a definition in a header file, every code file that includes the header needs to be recompiled. One small change can cause you to have to recompile your entire project!
Sometimes exceptions are made for trivial functions that are unlikely to change (e.g. where the function definition is one line).
</blockquote>
Source: <a href="http://archive.li/ACYlo" rel="nofollow noreferrer">http://archive.li/ACYlo</a> (previous version of Chapter 1.9 on learncpp.com)

I have a class which has many small functions. By small functions, I mean functions that doesn't do any processing but just return a literal value. Something like:

<pre><code>string Foo::method() const{
 return "A";
}
</code></pre>

I have created a header file "Foo.h" and source file "Foo.cpp". But since the function is very small, I am thinking about putting it in the header file itself. I have the following questions:

<ol>
<li>Is there any performance or other issues if I put these function definition in header file? I will have many functions like this.</li>
<li>My understanding is when the compilation is done, compiler will expand the header file and place it where it is included. Is that correct?</li>
</ol>

Writing function definition in header files in C++

编译器

我有一个类，它有很多小函数。说到小函数，我指的是那些不做任何处理而只返回一个文字值的函数。类似于：string Foo::method() const{    return "A";}我已经创建了一个头文件"Foo.h“和源文件"Foo.cpp”。但由于该函数非常小，我正在考虑将其放入头文件本身。我有以下问题：如果我将...

问在C++中编写头文件中的函数定义
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C++中编写头文件中的函数定义EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C++中编写头文件中的函数定义
EN