Library standardization

[e-t172]

Janice Caron a écrit :
> That assumption is false. Just because a function is small enough to
> be inlined, doesn't mean its object code won't be in the library. In
> fact, if I understand this correctly, the object code will always be
> in the library.
> 
> The decision as to whether or not to inline cannot be made at the
> library level. To make that decision most optimally, the compiler also
> needs to know the calling code.
> 
> If all calls to a function are inlined, the linker should not link it
> into the final executable, thereby avoiding code bloat.

True. But that does not resolves the problem of a general update to the 
shared library (see my reply to myself).

My point is, inlining functions without the developer's consent is 
likely to cause grave problems when writing shared libraries. There 
should be a way to tell the compiler "Hey, I want you NOT to inline this 
function, even if that sound stupid, because I want it to be in MY 
shared library, so I can update it whenever I want". Maybe the export 
attribute does this already, as Bill Baxter was suggesting.