5 ms·
For C++ (C and C++ differ a lot here): https://en.cppreference.com/w/cpp/language/inline https://en.cppreference.com/w/cpp/language/inline The most common use
by zabzonk 5y ago
For C++ (C and C++ differ a lot here): https://en.cppreference.com/w/cpp/language/inline https://en.cppreference.com/w/cpp/language/inline
The most common use of inline in C++ is to define a function in a header file that is potentially #included in multiple source files. Without the inline specifier, this would result in multiple definition errors at link time.
It's an example (there are several in C++) of reusing syntax/semantics to replace something no-one does (trying to get the compiler to inline code) with something that is useful.
- ridiculous_fish 5y agoRight, the inline keyword in C++ is mainly used to dodge ODR. When you really care about inlining, you want an attribute like always_inline, which emits an error if the function cannot be inlined (e.g. is recursive).
- varajelle 5y agoLittle to do with ODR. The inline function must have the same tokens in every translation unit otherwise it is undefined behaviour.
- dataflow 5y agoSame tokens? So you're saying 'inline int foo(void);' + 'typedef int I; inline I foo(void);' is UB?
- MauranKilom 5y agoQuoting the C++ 17 standard draft [0]: > There can be more than one definition in a program of [...an] inline function [...] as long as all of the following is true: > - each definition consists of the same sequence of tokens (typically, appears in the same header file) > [...] > If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the program is ill-formed, no diagnostic required. [0]: https://timsong-cpp.github.io/cppwp/n4659/basic.def.odr#6.1 https://timsong-cpp.github.io/cppwp/n4659/basic.def.odr#6.1
- xxpor 5y agoNo one tries to get the compiler to inline code? What? Doing a function call is quite expensive! If you're not worried about that level of performance why are you using C these days in the first place?
- jeffbee 5y agoThe only legitimate way to influence the compiler's inlining decisions is by profile guidance. If you aren't providing a profile at compile time, you demonstrably do not care about performance.
- google234123 5y agoWhat a lazy generalization. Shame!
- 1ris 5y agoBut it's mostly true. Trust the compiler. They are very, very good. They have a better understanding of the performance characteristics of the current platform with the current code than the programmer. Another benefit is you do not need to maintain and update the manual optimisations once one assumption has changed. __force_inline does more bad than good. (some compilers these days have whole programm optimisation and outlining, things that make the decision when to inline and when not to inline even harder for humans)
- account42 5y agoI agree that in an ideal world function boundaries would be primarily for readability and at most a minor hint to compilers. But I also think youthat give compilers way too much credit. Compilers are still generally applying one relatively simple rule after another. Often that will get good results, but it sometimes fails in surprising ways because the compiler will not be able to predict the effect of one optimization on later ones. This is where hints such as "always inline" are useful, and that doesn't even have to do anything with the target platform. And as for PGO, yes that's useful, but it's also not a silver bullet: a) mentioned above, thresholds for local optimizations (which is what PGO affects) are not always enough and b) getting a representative profile is not trivial and also needs to be kept up to date.