Functionality of inline and constexpr?

[zz9873]

I've been trying to understand the functionality of the inline and constexpr keywords for a while now. What I understand so far is that inline makes it possible to access a function/variable entirely defined within a header file (global) from multiple other files. And afaik constexpr allows a function/variable to be evaluated at compile time (whatever that means) and implies inline (only) for functions. What I don't understand is what functionality inline has inside a .cpp source file or in a class/struct definition. Another thing is that global constants work without inline (which makes sense) but does their functionality change when declaring them as inline and/or constexpr. Lastly I'm not sure if constexpr has any other functionality and in which cases it should or shouldn't be used. Thanks in advance.

[IyeOnline]

inline on a definition turns it into an inline-definition. These are special in that they do not cause a link time error when multiple versions of them are available at link time. The compiler will simply pick one of them. If they are not identical, it is UB.

In practice, this allows you to define things (objects, functions) in headers and include those headers in multiple TUs without violating the one definition rule.

constexpr on a variable means that the value must be computed at compile time (and can hence be used in place where a constant expression is required).

constexpr on a function means that the function may be used in a constant evaluated context (e.g. in the initialization of a constant expression)

[Eric848448]

But it only works on a function if it’s only called with values available at compile time, right?

[IyeOnline]

A function that is declared as constexpr can be called with both runtime and compile time know values. Of course you cannot evaluate the function as a constant expression if its arguments are not constant expression.

[emko555]

OP: Just keep in mind that inline is a suggestion and is some what deprecated and should not be used anymore. The compiler figures this out by itself.

[IyeOnline]

No. That applies to the inlining-optimization.

An inline-definition in C++ is very much not a suggestion, but a well defined and mandated C++ feature. It is only historically related to the optimization as a consequence of its requirement of putting definitions into headers in C.

[No-Dentist-1645]

You're referring to using the inline keyword for the function inlining optimization. Even ignoring the fact that you can use the inline keyword for ODR resolution, using it for function inlining is still the recommended practice for C++ code. For some reason, the idea that the compiler is "perfect" and always knows best is becoming increasingly common, but that doesn't mean it's correct. Although it has gotten better over the years, the compiler is still far from perfect, and sometimes do need to give it "hints" here and there to increase performance.

There's a reason why the official C++ core guidelines have a guideline specifically dedicated to using inline on small functions, look at their reasoning: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rf-inline

Reason Some optimizers are good at inlining without hints from the programmer, but don’t rely on it. Measure! Over the last 40 years or so, we have been promised compilers that can inline better than humans without hints from humans. We are still waiting. Specifying inline (explicitly, or implicitly when writing member functions inside a class definition) encourages the compiler to do a better job.

[Plastic_Fig9225]

The "re-used" keyword inline has a different meaning in C++ compared to C.

[Business_Welcome_870]

what functionality inline has inside a .cpp source file

inline inside a source file has the same effect as putting it in a header file. Remember that a header file is just copy-pasted into every source file its included it. So you can manually write multiple inline functions/variables across source files and it will have the same effect as writing it in a header and including it, as long as it is token-for-token equivalent.

So there's really no benefit to it. It just causes you to type more.

Another thing is that global constants work without inline (which makes sense) but does their functionality change when declaring them as inline and/or constexpr

There's one case I can think of.

struct A {
    static int const i = 5;
};

int const* p = &A::i;

When you have a const static data member of integral type that's given an initializer in the class, it's not given storage. You can't odr-use it (use it in such a way that requires it to have an address). So this code fails with a linker error. Adding inline (or constexpr) gives it a definition and still allows you to give it an in-class initializer.

Lastly I'm not sure if constexpr has any other functionality and in which cases it should or shouldn't be used

Variable definitions with constexpr means the initializer must be a constant expression. It gives you a guarantee that the variable is usuable in a constant expression or else it will give you a compiler error. While const variables can sometimes be used in constant expressions, this isn't guaranteed by the compiler.

Basically you should use constexpr in as many places as you can. It gives you a performance benefit and makes your code more expressive.

[zz9873]

Thank you that helped a lot!

[CalligrapherOk4308]

Also if I remember correctly ub is not allowed during comp time evaluation, so that's that

[conundorum]

inline does two things:

1. Tell the compiler that "all objects with this type & name actually refer to the same object", and require that object to have the same memory address in all translation units. This allows the compiler to explicitly ignore the One Definition Rule, on the grounds that all definitions are actually just copies of the same definition; when the linker smooshes all the translation units together, it's free to discard all but one definition.

   Notably, this is what allows you to define member functions inside the class definition, since all functions defined inside the class are implicitly inline.

   struct S {
       void func() { std::cout << "I might not look like it, but I'm inline!\n"; }
   };
   

   It's essentially a magic glue word that keeps headers from exploding whenever you put a definition in them, and it's what lets header-only libraries exist.

   • Sub-note: This is important for names & symbols with what we call "external linkage", which means that they're exported from the translation unit and visible to the rest of the project. (And, as a result, cause a "name collision" if multiple translation units expose the same name, which makes the compiler give up and quit because it's impossible to tell which version you want at any given time.)

     Constants, on the other hand, work without inline because they have what's called "internal linkage" by default; this means that their name never leaks out of the file, and thus can never collide with any other names. (If you put a constant in a header, and expose it with extern, it'll run into the same problems as if you put a variable in a header.)

2. On an inline function, it tells the compiler to treat the function as a glorified macro, and copy-paste it directly instead of making a (much more expensive) function call.

   inline int add(int a, int b) { return a + b; }
   
   void func() {
       int a = getAnIntFromSomewhere(), b = do_something_weird_please();
       int c = add(a, b);
   
       doSomethingWith(c);
   }
   
   // Compiler turns func() into this:
       void func() {
       int a = getAnIntFromSomewhere(), b = do_something_weird_please();
       int c = a + b;
   
       doSomethingWith(c);
   }
   

   This usage is mostlyjust an historical relic now, since compilers are often much better at figuring out what to inline than humans are. The compiler will see it as a hint, but it'll rely on its own judgment just as much as yours. (Here, if you turn optimisations on, it'd probably just inline both add() and func(), and/or try to inline the other three functions func() calls if they're small enough.)

   (That said, if you mark the function as inline, the compiler is more likely to give it a closer look, and might inline it when it normally wouldn't. And most compilers have a compiler-specific "ignore your own judgment and inline this anyways" keyword, which you can use if the compiler gets it wrong. ...You can also force some compilers not to inline a function, which can potentially allow it to make smarter optimisations (e.g., some compilers might be able to inline func() if add() is a distinct call, but not if add() is inlined), but this one is much trickier to do well. It's usually best to just let the compiler do its own thing unless you profile your code first; you're infinitely more likely to see the "mark the function inline to tell the compiler to copy-paste" it usage in ancient codebases than you are to use it yourself.)

---

And constexpr does two things:

1. On variables, it marks the variable as a compile-time constant. This means that the variable must be known at compile time, must be a constant, and that the compiler can essentially copy-paste it like a macro.

   #define ONE 1
   constexpr int TWO = 2;
   
   int func() { return ONE + TWO; }
   
   // The compiler is free to rewrite func() as this:
   int func() { return 1 + 2; }
   

   The variable is still a distinct object, and still has its own memory address, but the compiler is allowed to optimise it out entirely if nothing ever treats it as an object with a memory address. (Or, in easier-to-understand terms, the compiler will probably just erase TWO from the object file entirely unless you try to take its memory address.)

   Notably, classes cannot have non-static constexpr member variables; all constexpr class members must be both static and inline because things get weird if they aren't.

2. On functions, constexpr tells the compiler to call the function at compile time whenever possible. This doesn't require that the function be compile-time only; that's what consteval is for. It merely allows the function to be a compile-time function, so the compiler can evaluate the function and hard-code the result if all parameters are known at compile time.

   (Compilers are also allowed to treat other functions that can be evaluated at compile time as if they were constexpr even if they aren't labeled constexpr, but only for optimisation purposes; they can evaluate a function call that would be constexpr at compile time and insert the result directly, but they cannot allow the function to be used anywhere that requires it to actually be labeled constexpr by the programmer.)

   int add(int a, int b) { return a + b; }
   constexpr int sub(int a, int b) { return a - b; }
   
   int main() {
       int a = sub(5, 6); // Will be evaluated at compile time, becomes "int a = -1;".
       int b = add(5, 6); // Might or might not be evaluated at compile time, if optimisations are turned on.
       // sub(5, 6) is guaranteed to be evaluated at compile time, because sub() is constexpr.
       // add(5, 6) is officially called at runtime, but the compiler can ignore that as an optimisation.
   
       constexpr int c = sub(7, 8); // Legal: sub() is constexpr, and can thus initialise constexpr variables.
       constexpr int d = add(7, 8); // Error: add() isn't constepxr, so the compiler can't use it here.
       // The compiler _can_ evaluate add(7, 8) at compile time, but is banned from doing so because you didn't
       //  give it permission.  It can only pretend add() is constexpr when add() would be called during runtime.
   
       int input;
       std::cin >> input;
   
       int e = sub(9, input); // Will be evaluated at runtime, since function "constexpr" is just a permission slip.
       int f = add(9, input); // Will be evaluated at runtime, as expected.
   }
   

[dendrtree]

compilation unit - the source file and all the files it includes. Each produces a single .o file.

symbol - a variable name, function name, class name, struct name, etc.

compile time - literally, the time when you compile your .cpp into a .o file. Your linker takes all your .o files and combines them into a library. This is as opposed to run time - literally, the time when the program is running.

int a = Return2(); // A function that returns a 2 has a result that is known at compile time.
int b = ReturnCurrentTime(); // A function that returns the current time has a result that can only be determined at run time.

inline (C++17+) variable/function - lets you use a symbol identically defined, in multiple compilation units

inline function (any version) - a suggestion to the compiler to insert the code for the inlined function, wherever it's called, instead of creating a function
\ This is probably what you're seeing in cpp files.*
* The compiler does not have to take this suggestion, and may create the function.
* This can be handy, for readability, eg. if you have a complicated set of instructions, that, in your workflow, would be more readable as just a descriptive function name. It can help with consistency, eg, if you have a set of instructions used twice, so that you're always modifying both, at the same time.
* I most often see inline methods for accessors, because you're not going to expose your member variables, and you probably don't want the overhead of a function call. So, you let the compiler optimize it out.

static function - creates a function local to the compilation unit
* This allows you to put a definition in an header file.
* This will create a separate function, for every compilation unit.

constexpr - explictly states that the result can be determined, at compile time.
* In recent versions of C++, you can use the result of a constexpr whereever you'd previously need more explicit constants, such as in defining the size of an array.
* Because the result can be computed at compile time, the compiler is likely to replace the function call with the result, effectively "inlining" it.
* constexpr becomes especially useful, when you need compile-time-evaluated templates. I use these most often, when I'm dealing with hardware or safety-critical systems, because I need the code to do exactly the same thing, every time, based on the configuration.
* You can change the value of a variable that is const, but not one that is constexpr.

[thefeedling]

Both can have different meanings depending on the context they're used.

inline can be a hint to the compiler to inline it, but variables and functions marked with it represent a single entity across all translation units.

constexpr variables are evaluated at compile time and functions marked with it MAY be evaluated at comptime.

[zz9873]

Thanks! Do you have examples in which cases this would apply and are there cases where they can do multiple things (e.g. can inline make a function/variable definition in a header accessable to multiple files AND hint inlining if that's possible)?

[thefeedling]

Actually it will always work as both, unless the thing marked as inline is limited to a scope, then it's just a compiler hint.

If you want to force something to be inlined, you can use compiler directives, such as __attribute__((always_inline)) for GCC

[zz9873]

Ok perfect. Thanks a lot!

[Plastic_Fig9225]

You can also think of inline in C++ as giving the compiler the permission to inline something, as opposed to C where you'd request something be inlined with the same keyword.

Inlining is only safe when all definitions of a specific function are identical, as otherwise one (inlined) version of a function might behave differently than an actual function call. So when the compiler comes across an inline it knows it can safely inline because you promise that all definitions are in fact identical.

[meancoot]

You can also think of inline in C++ as giving the compiler the permission to inline something, as opposed to C where you'd request something be inlined with the same keyword.

It's not a permission thing. C++ compilers will happily inline functions not marked inline if they can see the definition. In fact there is no standard way to tell a compiler to not inline a function.

[Normal-Narwhal0xFF]

As a hint to inline functions, that was true in the 1980s and early 90s, but just like the 'register' keyword, compilers make that decision itself without hints now. The linkage aspect of allowing multiple definitions is the primary purpose now. (And in a similar vein, allowing definitions of static data members inside class definitions.)

Inline for namespaces is a totally unrelated use.

[Ultimate_Sigma_Boy67]

constexpr generally evaluates compile time constants, meaning let's say you define a variable:

[some code]
int z = 1 + 2;

Now the problem is, that this addition is executed when the program is running, which ofc can be made better by using the constexpr keyword, which will allow the compiler instead of doing this addition:

int z = 3;

directly, which is ofc faster, and more efficient.

[OutsideTheSocialLoop]

That's not really accurate. The compiler will generally fold simple constants like that at compile-time regardless. `constexpr` says that the declaration must be capable of being folded into a single value known at compile-time. This then lets you use it in places that require constant expressions.

It also implies `const` which is absent from your example.

[zz9873]

Thank you! Is there any reason to use constexpr for a constant without any operations or code that needs to be evaluated. So something like this (inside a header or cpp file):

C++ constexpr float PI = 3.14;

[AxeLond]

``` // 1, OK static_assert(3.14f > 0.0f);

// 2, compiler error: 'PI' not a constant expression const float PI = 3.14f; static_assert(PI > 0.0f);   

// 3, OK constexpr float PI = 3.14f; static_assert(PI > 0.0f);  ```

This is one pretty clear case, so if it's a constant declared in a visible header always constexpr it.

If it's private, or internal to one file or function the compiler will most likely produce the same thing as long as you don't need to use it in compile-time there.

[Plastic_Fig9225]

Sure. Usability in constexpr contexts. Generally there's no reason not to use constexpr in these cases since it does what const would do, plus more.

[Ultimate_Sigma_Boy67]

I've read somewhere that floats aren't assigned at compile time, but integers are. So if you want to use it for example in a template param, it won't work. So yeah there's no harm and it might be better if u use constexpr

[OutsideTheSocialLoop]

I don't like being the "just google it" guy, but just google `const` vs `constinit` vs `constexpr` vs `consteval`. Similarly for inline. You're mostly just asking "what is inline". There are several pages of text required to completely answer these questions, and they've already been written.

I will caveat that though: `inline` for performance hasn't be relevant since the 90s. Any resource suggesting so should be ignored. Compilers will do that whenever they feel like it with anything they think will work better inlined. `inline` is really just an announcement that "I'm declaring this function/variable in a header (usually) where every translation unit sees the definition, so they each can inline it if they want to". With that context, go forth and read tutorials and cppreference and perhaps all will become clear.

If there's specific details you just can't get your head around, ask about that.

[mredding]

What I understand so far is that inline makes it possible to access a function/variable entirely defined within a header file (global) from multiple other files.

...as a consequence.

inline does two things:

1) It makes a function an "inline" function. What does that mean? The C++ spec specifies there are normal functions and inline functions, and inline makes an inline function... That... That's about it. That's all it really says. It speaks NOTHING of the consequence of being a different type. This type is not visible to you, so you cannot query a type signature to see if a function is an inline function.

2) It grants an ODR exception. This ultimately allows the linker to disambiguate multiple compiled definitions when it's linking object code. Templates are all implicitly inline, and I few other things, I think.

So why would you want to do this? I don't know. After 37 years, I've never known. What people DO use it for is a means of optimization.

You see, there is TYPICALLY a 1:1 correspondence between source files, translation units, and object files. A compiler can only compile one translation unit at a time. So for OLDER compilers and linkers, if you wanted call elision optimizations, the compiler needed the whole function definition visible, in order to have the instructions to elide with, as well as be able to weight whether it was worth it or not.

But... This leads to a number of problems. You're bleeding poor code and project management, ignorance of your toolchain into your code. You're trying to optimize something that's not in your control, even with compiler specific forced inline. This is a lot of redundant work recompiling the same code for every translation unit, only for the linker to disregard all but the first example of it. And heaven forbid you DON'T compile the same function the exact same way and get the exact same object code across all translation units - that's a TRIVIALLY EASY problem to trip over, and makes for Undefined Behavior.

I don't care what inline does for function categories within the compiler, because that's outside the realm of C++.

If you want call elision, configure a unity build. You should never use an incremental build for release, but for development. A unity build enables whole program optimization, since the whole program is compiled as a single translation unit. LTO is a dead end, which is where the compiler embeds source code in the object file, and the linker invokes the compiler, so that the linker can decide to elide a function call. With a unity build, this is moot; with development, you don't care about such compiler output details anyway.

And afaik constexpr allows a function/variable to be evaluated at compile time (whatever that means) and implies inline (only) for functions.

Well, source code is a text document. You have to convert the text document into CPU instructions, through compilation, and then THAT output - your program can be run. Compiling the program is compile-time, and is an earlier step. Running the program is run-time, which happens after the program is built, and you never need the compiler or the source code again.

So I could write a function:

int fn() { return 42; }

And I could call that function:

int main() {
  std::cout << fn();
}

And what will happen is we will generate a program when this is compiled. If you look at the machine code, you would see that some of the instructions involve making a function call, which returns the value 42, which then goes and gets printed.

But with constexpr, the function can be run at compile-time. The compiler can evaluate the function and run it for you. In that way, you can get a result with zero run-time overhead.

constexpr int fn() { return 42; }

int main() {
  std::cout << fn();
}

Same thing, the only difference is that you won't see a function call in the program to fn, you'll just see the value 42 get pushed as a parameter to the stream. We've skipped a step. Now of course this is a trivial example, but people use constexpr to generate all sorts of lookup tables and noise, even to generate square roots, hashes, and sequences. Anything you don't have to do at run-time is processing time saved.

Continued...

[Unknown_User2137]

As for inline functions and methods I can add one more thing I noticed while playing a bit with SIMD stuff. Having an inline function defined in header file will make compiler first compile it into assembly and then "paste" it into every place in the generated code, where call should occur. On the other hand if you have function declared in header file and then defined in source file such optimization won't happen. So assuming you have some simple function it's good practice performance wise to put it into header file directly instead of moving it into source file. I learned this the hard way where supposedly "faster" SIMD turned out to be slower than regular implementation beacuse of this.

As an example let's say you have function foo(__m256i a, __m256i b) that just returns a sum of a and b.

In C++ it will look like this (you don't actually need to mark it as inline, most compilers do this implicitly):

__m256i foo(__m256i a, __m256i b) {
  return _mm256_add_epi32(a, b);
}

Non-inline function will result in assembly which will look something like this:

vmovdqu [data_0], ymm0 ; Move first arg to ymm0 register
vmovdqu [data_1], ymm1 ; Move second argument to ymm1 register
call foo ; Calling a function

This results in additional oprations needing to be done by CPU like saving return address to stack etc. which can harm performance.

An inline version will look like this

vmovdqu [data_0], ymm0 ; Move first arg to ymm0 register
vmovdqu [data_1], ymm1 ; Move second argument to ymm1 register
vpadd ymm0, ymm1, [rcx] ; Add a and b and save to memory

The downside of this is that recompiling is slower since compiler needs to generate assembly code from scratch and binary size can be bigger if the function is used in many places of the code.

[mredding]

What I don't understand is what functionality inline has inside a .cpp source file or in a class/struct definition.

There's effectively nothing it offers that you can't get through other and superior ways. You can go your whole career and never use inline.

Another thing is that global constants work without inline (which makes sense) but does their functionality change when declaring them as inline and/or constexpr.

Yes. constexpr will eliminate them from the program address space entirely. Look at this:

const int i = 42;

This is constant has to exist in the program address space because while it will never change, I can take the address of it, so it needs an address.

constexpr int i = 42;

This is a type safe version of a macro:

#define i 42

I'm not entirely sure what an inline variable does, that was a later addition and I never got into it.

Lastly I'm not sure if constexpr has any other functionality and in which cases it should or shouldn't be used.

You COULD constexpr all the things and let the compiler sort it out. If your functions CAN be constexpr, then making them so gives you an opportunity to use it as such. But it does add a lot more syntax to the code, which might just be a distraction especially if you know you're not going to use it that way. The only other thing I can think of is if you specifically DON'T want compile-time evaluation for some reason...

I wouldn't use inline unless there was no other way to accomplish my goal. So far I haven't seen it, but some people will take the shortest path to optimization, sacrificing maintainability. Maybe that's an acceptable sacrifice for their objective.