You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our codebase has a bunch of uses of the inline keyword. This used to be useful with early compilers, but now is just extra fluff to read. (I just ran a perf suite on all renderings and there's no change with or without inline hints). We should eliminate these.
The text was updated successfully, but these errors were encountered:
Sigh. I fell for it. In C++ inline does two completely different things:
It poorly hints to the compiler to perform the inline optimization (eliminate the function call overhead, inject the function code directly as appropriate, and/or maybe perform broader optimizations of the code in the context of the larger function. I say "poorly" because at this point compilers can determine if this is a Good Thing better than you can, and on the universe of compilers and platforms and compilation switches et cetera.
You know how in C++ static means like six different things that are only vaguely related to the actual word static? Well, inline is like that too. It tells the linker that it may encounter a function definition in multiple translation units. I believe that it's undefined which function definition wins, but there's anecdotal evidence that the first definition wins. In other words, if the linker sees inline int foo { return 1; } and inline int foo { return 2; }, it may always use the first and discard the second.
For our code as implemented it doesn't matter, since each program has a single translation unit, starting at main.cc. However, if a reader chose to do their implementation with headers and source files separated, then without the inline keyword, they'd start seeing multiple function definitions, and the associated errors from that.
For this reason, common functions outside of classes should get the inline keyword. As an alternate implementation, we might choose to define a common utility function as a static function inside a related class. In this scenario, classes operate as de facto namespaces, and the method definition inside a class definition functions in the same way that the inline keyword does for functions outside of classes.
Our codebase has a bunch of uses of the
inline
keyword. This used to be useful with early compilers, but now is just extra fluff to read. (I just ran a perf suite on all renderings and there's no change with or without inline hints). We should eliminate these.The text was updated successfully, but these errors were encountered: