int frozen(int arg) {return arg + 23;}
>>5
Agreed. You should generally not worry about this at all during development because it's an optimization step that a) has hard to predict results (making even small functions inline might significantly worsen performance), and b) is extremely easy to change at the end of the development cycle (just move the dang thing to the header file and put 'static inline' in front.) The best solution is of course to let the compiler do it for you; use PGO and LTO where available (and turn off default inline for class scope functions) so you never have to think about manually inlining anything.
Inlining too much can also cause excessive header file dependencies; if an inline function calls another function, you have to move its include to your own header file, causing more dependencies and longer rebuild cycles. If in doubt, don't inline.
That being said, when writing a function like the above, I will put it in the header file as static inline upon writing, since a) the current platforms I'm targeting don't support LTO, b) it's obvious that optimizes down to a single processor instruction on almost all architectures, c) it doesn't require any header file dependencies, and d) it's typesafe (as opposed to a macro).