constexpr函数是指能用于常量表达式的函数。定义constexpr函数的方法有其他函数类似,不过要遵循几项约定:函数的返回值类型及所以形参的类型都是字面值类型,而且函数体中必须有且只有一条return语句。为了能在编译过程中随时展开,constexpr函数被隐式指定地指定为内联函数。
constexpr函数体内也可以包含其他语句,只要这些语句在运行时不执行任何操作就行。例如,constexpr函数中可以有空语句、类型别名以及using声明。
允许constexpr函数的返回值并非一个常量:
constexpr int scale(int cnt){return 5*cnt;}//如果arg是常量表达式,则scale(arg)也是常量表达式
当scale的实参是常量表达式时,它的返回值也是常量表达式;反之则不然。如果我们用一个非常量表达式调用scale函数,比如int类型的对象i,则返回值是一个非常量表达式。当把scale函数用在需要常量表达式的上下文时,由编译器负责检查函数的结果是否符合要求。如果结果恰好不是常量表达式,编译器将发出错误信息。constexpr函数不一定返回常量表达式。
把内联函数和constexpr函数放在头文件内
和其他函数不一样,内联函数和constexpr函数可以在程序中多次定义。毕竟,编译器要想展开函数仅有函数声明是不够的,还需要函数的定义。不过,对于某个给定的内联函数或者constexpr函数来说,它的多个定义必须完全一致,基于这个原因,内联函数和constexpr函数通常定义在头文件中。
https://www.cufe-ifc.org/question/153643.html
(C++ Primer 第5版 215页) 而且,书中有说:“对于某个给定的内联函数或者constexpr函数来说,它的多个定义必须完全一致。基于这个原因,内联函数和constexpr函数通常定义在头文件中”。 为什么放在源文件里就不可以了呢? 我用网上的例子(浅谈C++中内联关键字inline)运行了一下: A.h #pragma once class A { public: A(int a, int b) : a(a), b(b) {} int max(); private: int a; int b; }; A.cpp #include "A.h" inlin…
其他回答
能定义不止一次的好处是方便你放到头文件里,头文件里的好处是每个include这个头文件的.c文件都能函数体,看到函数体的好处是编译器可以内联。内联的好处是代码变快了。另外,所有函数体定义必须一模一样,不然出了问题概不负责。constexpr自带inline属性。
当你下决心在.c文件中定义函数体的时候,自然不需要inline关键字了。而这时候也必须link相应的.o来确保找得到定义。
------------------------------ 话痨版 ------------------------------
首先来几个前置知识:
1) C和C++都有translation unit(或compilation unit)的概念:基本上编译器会一次编译一个文件,然后忘记一切,然后再编译下一个文件。哪怕你写gcc -c a.c b.c,其实和gcc -c a.c && gcc -c b.c大体上是没区别的。在最后,所有的.o文件都被linker汇总link成一个大的可执行文件。
2) static function。你可以把一个函数标记为static(也称为internal linkage),这样该函数的symbol就会被隐藏,从而该函数只存在在当前translation unit。换了下一个translation unit之后,该函数被忘得一干二净。linker也从来不知道这函数存在过。这时候你就算再定义一次上次translation已经定义过的static函数,linker也不会报redefinition错误。当然,这样代码在binary中就出现了多次。
3) 当然你也肯定知道C和C++的include的意思:在A中#include <B>就是把B的内容复制粘贴到A中#include对应的位置。
4) 编译器的内联优化就是看到你在Bar里调用Foo的时候,帮你复制一遍Foo的函数体,内嵌到Bar里去,同时消除栈操作的开销(因为代码已经被复制到“本地”了嘛,不需要跳来跳去了)。内联优化有个缺陷,就是在同一个translation unit里一定要看到函数体,所以光看到declaration是没用的。
现在考虑这么个问题:传统的在头文件中声明,在一个文件(.c)中实现函数体的方式有时执行太慢了。为什么慢呢,假设我这个函数就一行,但是函数调用的压栈传参数弹栈跳转等指令占了大部分开销,真是太不合算了。
这时候在传统C里面有两个解决方案:
1) “宏函数”。就是把本来藏在.c文件里的函数体放到一个宏里面去,当然宏也在头文件里。然后大家include头文件的时候就把宏也include走了,使用宏的时候就把这段代码一遍遍展开到所有使用的地方,消除了函数调用的开销。
2) 在编译器支持内联优化的情况下,在头文件里定义static function。任何别的.c文件,只要include了你的头文件,都对你的头文件做了一次复制粘贴,自动获得了该static function的函数体。所以在不同的translation unit里面,这些函数并不冲突,因为它们是static的。值得一提的是,这些函数体不一定一模一样。举例来说:
在不同的translation unit里面一个Foo返回3一个返回2。
1) 的坏处很明显,宏不能解决类型检查的问题,宏是dynamic scope(变量检查环境都是调用端而非定义端的)的,宏是textual substitution,搞不好有迷之编译不通过,宏很丑,定义不带语法高亮(雾),等等。
2) 看上去很好诶,写的是真正的函数,编译器还有能力内联。其缺陷是在编译器决定不内联的时候(通常这时候函数很大),每个translation unit中都定义了一个很大的函数,造成了不必要的binary size bloat。
这时候C++之父Bjarne Stroustrup站出来了,说我们在C++里搞个inline关键字吧!这个关键字不仅编译器认识,而且编译器在没有真正内联该函数时,会通过某种方式提示linker说这个函数被标记为“可重复定义”耶 - 根据我用gcc的实验,生成的是一个weak symbol。当linker看到一个weak symbol,会把函数名写在一个小本本上。在linker最后把所有文件link到一起的时候,它会把小本本扫一遍,对于同名函数只留一个,别的函数连带函数体统统删掉。这样就解决了binary size bloat的问题。当然这只是一种典型实现方式,并非一定如此。
另外,在编译器真正内联了该函数的时候,效果就和static一样了,这也是为什么你的代码里找不到定义 - 因为linker根本看不到static函数。话虽这么说,但是他们不管这个叫internal linkage(inline specifier),因为此时linkage是个implementation detail。语言只是强调:
在前面提到,用include static functions的方式中include进来的函数体可能不完全一样。inline此处也提到,你要是同名函数的函数体长得不一样,我才不告诉你我要留哪一份删哪几份呢。你要是敢这么做,我不保证我的输出有意义。这个在C++里叫做ODR violation (Definitions and ODR)。编译器一次只看一个translation unit,所以通常是没法检测ODR violation的(不排除LTO还是能查的),而linker也不查,我并不清楚为什么,大概是太昂贵吧。
另外,可以感受下当年inline关键字的marketing口号:
“An Inline Function is As Fast As a Macro”(Inline - Using the GNU Compiler Collection (GCC))
顺带建议一下刷ACM-ICPC的各种坑爹oj的同学,想要速度就用宏,因为oj可能不开内联优化。。
当你下决心在.c文件中定义函数体的时候,自然不需要inline关键字了。而这时候也必须link相应的.o来确保找得到定义。
------------------------------ 话痨版 ------------------------------
首先来几个前置知识:
1) C和C++都有translation unit(或compilation unit)的概念:基本上编译器会一次编译一个文件,然后忘记一切,然后再编译下一个文件。哪怕你写gcc -c a.c b.c,其实和gcc -c a.c && gcc -c b.c大体上是没区别的。在最后,所有的.o文件都被linker汇总link成一个大的可执行文件。
2) static function。你可以把一个函数标记为static(也称为internal linkage),这样该函数的symbol就会被隐藏,从而该函数只存在在当前translation unit。换了下一个translation unit之后,该函数被忘得一干二净。linker也从来不知道这函数存在过。这时候你就算再定义一次上次translation已经定义过的static函数,linker也不会报redefinition错误。当然,这样代码在binary中就出现了多次。
3) 当然你也肯定知道C和C++的include的意思:在A中#include <B>就是把B的内容复制粘贴到A中#include对应的位置。
4) 编译器的内联优化就是看到你在Bar里调用Foo的时候,帮你复制一遍Foo的函数体,内嵌到Bar里去,同时消除栈操作的开销(因为代码已经被复制到“本地”了嘛,不需要跳来跳去了)。内联优化有个缺陷,就是在同一个translation unit里一定要看到函数体,所以光看到declaration是没用的。
现在考虑这么个问题:传统的在头文件中声明,在一个文件(.c)中实现函数体的方式有时执行太慢了。为什么慢呢,假设我这个函数就一行,但是函数调用的压栈传参数弹栈跳转等指令占了大部分开销,真是太不合算了。
这时候在传统C里面有两个解决方案:
1) “宏函数”。就是把本来藏在.c文件里的函数体放到一个宏里面去,当然宏也在头文件里。然后大家include头文件的时候就把宏也include走了,使用宏的时候就把这段代码一遍遍展开到所有使用的地方,消除了函数调用的开销。
2) 在编译器支持内联优化的情况下,在头文件里定义static function。任何别的.c文件,只要include了你的头文件,都对你的头文件做了一次复制粘贴,自动获得了该static function的函数体。所以在不同的translation unit里面,这些函数并不冲突,因为它们是static的。值得一提的是,这些函数体不一定一模一样。举例来说:
// a.h
#define FOO 3
static int Foo() { return FOO; }
// a.c
#include "a.h"
// b.c
#undef FOO
#define FOO 2
#include "a.h"
1) 的坏处很明显,宏不能解决类型检查的问题,宏是dynamic scope(变量检查环境都是调用端而非定义端的)的,宏是textual substitution,搞不好有迷之编译不通过,宏很丑,定义不带语法高亮(雾),等等。
2) 看上去很好诶,写的是真正的函数,编译器还有能力内联。其缺陷是在编译器决定不内联的时候(通常这时候函数很大),每个translation unit中都定义了一个很大的函数,造成了不必要的binary size bloat。
这时候C++之父Bjarne Stroustrup站出来了,说我们在C++里搞个inline关键字吧!这个关键字不仅编译器认识,而且编译器在没有真正内联该函数时,会通过某种方式提示linker说这个函数被标记为“可重复定义”耶 - 根据我用gcc的实验,生成的是一个weak symbol。当linker看到一个weak symbol,会把函数名写在一个小本本上。在linker最后把所有文件link到一起的时候,它会把小本本扫一遍,对于同名函数只留一个,别的函数连带函数体统统删掉。这样就解决了binary size bloat的问题。当然这只是一种典型实现方式,并非一定如此。
另外,在编译器真正内联了该函数的时候,效果就和static一样了,这也是为什么你的代码里找不到定义 - 因为linker根本看不到static函数。话虽这么说,但是他们不管这个叫internal linkage(inline specifier),因为此时linkage是个implementation detail。语言只是强调:
The definition of an inline function must be present in the translation unit where it is called (not necessarily before the point of call)
在前面提到,用include static functions的方式中include进来的函数体可能不完全一样。inline此处也提到,你要是同名函数的函数体长得不一样,我才不告诉你我要留哪一份删哪几份呢。你要是敢这么做,我不保证我的输出有意义。这个在C++里叫做ODR violation (Definitions and ODR)。编译器一次只看一个translation unit,所以通常是没法检测ODR violation的(不排除LTO还是能查的),而linker也不查,我并不清楚为什么,大概是太昂贵吧。
另外,可以感受下当年inline关键字的marketing口号:
“An Inline Function is As Fast As a Macro”(Inline - Using the GNU Compiler Collection (GCC))
顺带建议一下刷ACM-ICPC的各种坑爹oj的同学,想要速度就用宏,因为oj可能不开内联优化。。
对于内联函数而言,其比较大的特点就是会在函数调用的地方被直接展开,而不是一个函数调用,从而减少函数的调用开销。而若是函数调用的话,我们可以在使用函数前的时候,如int foo()的方式,然后让后面的链接器去其它的目标文件进行函数符号的查找。
我来仔细的一步一步的分析这里面产生的缘由,我使用gcc作为演示,因为Linux有一系列的工具可以方便查看,但是这和Visual C++的原理是一致的。
回到你的例子,我们使用g++ -c http://main.cc -o main.o,然后使用nm main.o | c++filt 来查看生成的符号,如下图所示:
我们可以很清晰的看到A::max()的符号是U,即undefined,所以,它希望链接器去其它的地方找到函数的定义。若是一切正常的话,那么我们还有一个A.cpp,然后生成一个a.o,链接器去a.o的地方就可以找到这个函数定义了。
然而我们去编译其实现文件查看其符号表:
我们可以发现,是没有这个符号表的,因为如前文所述,inline函数并不会生成函数调用,会就在本源文件中展开,于是也就没有了函数的符号。
那么正是如此,后面链接器,把产生的.o合并到一起的时候,A::max()依然是未定义的,如下图所示:
那么,若是非内联的情况呢?
我们可以发现,a.o就会产生A::max()的函数符号,这样的话,若链接器去链接main.o a.o :
我们就会发现main.o 带U标记的undefined的A::max()被寻找到了,并在最后的.o中进行了填充。
那么,为什么inline的函数定义放在头文件就可以呢?因为我们使用的时候,会#include "a.h",那么这个时候编译器首先会预处理展开,这样也就包括了A::max()的定义,使用g++ -E http://a.cc > a.i; vim a.i 后如下图所示:
那么这个时候,http://main.cc在本源文件就可以找到A::max()的定义了,然后让我们看最后的符号表:
也的确如我们意想的不是U的undefined。
那么,这里多提一句的是,在现代的C++编译器中,我们几乎都做一个优化叫做内联函数优化,因为我们在优化的时候,若不是IPA这样的都是以一个函数来进行,那么我们内联函数优化后就会把相关的定义展开在一个函数中,这样就可以进行更好的优化。而这个内联函数的优化级别,在每一个编译器中是不同的,但是在我们实际C++编译器的实现中,其实已经完全不是很多教科书提到的几行了,我们往往是100行,乃至更多行的函数都会内联展开,就是为了更好的优化。而我们内联优化的话,其实也就是根据你的函数是多少行来进行决定的,于是在现代C++编译器中,如果你是为了inline优化而加上inline的话,我认为inline的意义在这里已经完全不需要了,现代的C++编译器优化已经非常强悍了。所以,若将来inline被C++废弃,也是完全可以理解的。
我来仔细的一步一步的分析这里面产生的缘由,我使用gcc作为演示,因为Linux有一系列的工具可以方便查看,但是这和Visual C++的原理是一致的。
回到你的例子,我们使用g++ -c http://main.cc -o main.o,然后使用nm main.o | c++filt 来查看生成的符号,如下图所示:
我们可以很清晰的看到A::max()的符号是U,即undefined,所以,它希望链接器去其它的地方找到函数的定义。若是一切正常的话,那么我们还有一个A.cpp,然后生成一个a.o,链接器去a.o的地方就可以找到这个函数定义了。
然而我们去编译其实现文件查看其符号表:
我们可以发现,是没有这个符号表的,因为如前文所述,inline函数并不会生成函数调用,会就在本源文件中展开,于是也就没有了函数的符号。
那么正是如此,后面链接器,把产生的.o合并到一起的时候,A::max()依然是未定义的,如下图所示:
那么,若是非内联的情况呢?
我们可以发现,a.o就会产生A::max()的函数符号,这样的话,若链接器去链接main.o a.o :
我们就会发现main.o 带U标记的undefined的A::max()被寻找到了,并在最后的.o中进行了填充。
那么,为什么inline的函数定义放在头文件就可以呢?因为我们使用的时候,会#include "a.h",那么这个时候编译器首先会预处理展开,这样也就包括了A::max()的定义,使用g++ -E http://a.cc > a.i; vim a.i 后如下图所示:
那么这个时候,http://main.cc在本源文件就可以找到A::max()的定义了,然后让我们看最后的符号表:
也的确如我们意想的不是U的undefined。
那么,这里多提一句的是,在现代的C++编译器中,我们几乎都做一个优化叫做内联函数优化,因为我们在优化的时候,若不是IPA这样的都是以一个函数来进行,那么我们内联函数优化后就会把相关的定义展开在一个函数中,这样就可以进行更好的优化。而这个内联函数的优化级别,在每一个编译器中是不同的,但是在我们实际C++编译器的实现中,其实已经完全不是很多教科书提到的几行了,我们往往是100行,乃至更多行的函数都会内联展开,就是为了更好的优化。而我们内联优化的话,其实也就是根据你的函数是多少行来进行决定的,于是在现代C++编译器中,如果你是为了inline优化而加上inline的话,我认为inline的意义在这里已经完全不需要了,现代的C++编译器优化已经非常强悍了。所以,若将来inline被C++废弃,也是完全可以理解的。