On a related note, I once read somewhere that if you inline (put implementation in class definition) the compiler will inline the object code, is this true? (I didn't believe it)

Maybe.

You should treat 'inline' as more of a hint which the compiler is likely to ignore; during compiling it will do various stages of analysis to decide if a function should be inlined or called directly depending on what is going on at the call site at that moment. This can mean that calling function 'foo' from two locations might result in it being inlined in one but not another. However this only applies to functions the compiler can see all of which is at the 'translation unit' level (pretty much a single .cpp + headers) as that is all the code it has access to; so if a function is fully defined in a header it can potentially be inlined.

Note the 'only code it can see' above; this is where link time code generation and whole program optimisation enters the picture.

The linker has a much more complete picture of the code and as such can run its own anaylsis to determine what to inline when. So this could result in a function being defined in one .obj file and called from two others being inlined in one case but not the other depending on the call site.

The code can also be physically moved around in the executable to try and improve locality (a function is only called in a few places, so if those places are close together then putting the function close to them is good) and this would require adjustment to the code itself (compiler might have used a 'long' jump but with the code moved locally the linker can emit the 'short' version instead).

Simply put the compilers do a lot of clever stuff these days, some better than others, and it is a very active area of research still when it comes to applying optimisations etc.