Library standardization

[Bill Baxter]

e-t172 wrote:
> 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.

Doesn't look like export affects it.

I think this is the relevant code:


dmd/src/dmd/func.c:

void FuncDeclaration::bodyToCBuffer(OutBuffer *buf, HdrGenState *hgs)
{
     if (fbody &&
	(!hgs->hdrgen || hgs->tpltMember || canInline(1,1))
        )
      ...

No mention of "if isExported" there.

--bb