GSOC Linker project

[Andrew Wiley]

On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
<schveiguy at yahoo.com>wrote:

> On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley <wiley.andrew.j at gmail.com>
> wrote:
>
>  On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy at yahoo.com
>> >wrote:
>>
>>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>>
>>> That's exactly what storing the interface in the object file does.  You
>>> don't need the source because the object file contains the compiler's
>>> interpretation of the source, and any inferred properties it has
>>> discovered.
>>>
>>>
>> Putting inferred purity into an object file sounds like a bad idea. It's
>> not hard to imagine this scenario:
>> -function foo in libSomething is inferred as pure (but not declared pure
>> by
>> the author)
>> -exeSomethingElse is compiled to use libSomething, and the compiler takes
>> advantage of purity optimizations when calling foo
>> -libSomething is recompiled and foo is no longer pure, and
>> exeSomethingElse
>> silently breaks
>>
>
> no, it just doesn't link.
>
>
>  Purity inference is fine for templates (because recompiling the library
>> won't change the generated template code in an executable that depends on
>> it), but in all other cases, the API needs to be exactly what the author
>> declared it to be, or strange things will happen.
>>
>
> I agree that's the case with the current object/linker model.  Something
> that puts inferred properties into the object file needs a new model, one
> which does not blindly link code that wasn't compiled from the same sources.
>

Then all you've done is to make attributes the author can't control part of
the API, which will force library users to recompile their code more often
for non-obvious reasons. Avoiding that is one of the points of shared
libraries.

I think we're actually talking about different contexts. I'm speaking in
the context of shared libraries, where I think the API needs to be exactly
what the author requests and nothing more. With object files, static
libraries, and static linking, I agree that this sort of thing could work
and wouldn't cause the same problems because it's impossible to swap the
library code without recompiling/relinking the entire program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120507/891b91bb/attachment.html>