March 16, 2010
Walter Bright wrote:
> Regan Heath wrote:
>> Walter Bright wrote:
>>> Regan Heath wrote:
>>>> Walter Bright wrote:
>>>>> Regan Heath wrote:
>>>>>> I expect this either isn't possible or falls into the 'possible up to a point' category.
>>>>>
>>>>>
>>>>> It's possible up to a point, that point being the parts of the program the compiler does not see.
>>>>
>>>> So.. isn't that the same point the current import dependency method stops at?
>>>
>>> No, because that's a runtime check.
>>
>> No, I'm no longer suggesting a runtime solution.
>>
>> How does 'unreachable code' detection in C/C++ compilers work?
> 
> It requires the source code so the compiler can look at it.
> 
>> Can you use something similar to figure out the order module static data is used?
> 
> Yes, but that fails when the compiler doesn't have the source code to look at.

Ahh.. I was naively assuming you were compiling all the source at the same time, but of course that's not necessarily true.

So, this needs to work when compiling modules seperately and then linking, likewise libraries, right?  Is that the problem you're referring to?

Couldn't you store a list of dependencies in usage order in the output of the compile (the .o[bj] file) and use these lists when linking to resolve module init order.  You would need to know the 'main' module for a starting point, but from there you should be able to create an ordering.  You'd probably want to treat a static library as a single dependency, likewise C libraries etc.

R
March 16, 2010
Regan Heath wrote:
> So, this needs to work when compiling modules seperately and then linking, likewise libraries, right?  Is that the problem you're referring to?

Yes.

> Couldn't you store a list of dependencies in usage order in the output of the compile (the .o[bj] file) and use these lists when linking to resolve module init order.  You would need to know the 'main' module for a starting point, but from there you should be able to create an ordering.  You'd probably want to treat a static library as a single dependency, likewise C libraries etc.

Then you'd have to essentially build the linker into the compiler.
March 17, 2010
Walter Bright wrote:
> Regan Heath wrote:
>> So, this needs to work when compiling modules seperately and then linking, likewise libraries, right?  Is that the problem you're referring to?
> 
> Yes.
> 
>> Couldn't you store a list of dependencies in usage order in the output of the compile (the .o[bj] file) and use these lists when linking to resolve module init order.  You would need to know the 'main' module for a starting point, but from there you should be able to create an ordering.  You'd probably want to treat a static library as a single dependency, likewise C libraries etc.
> 
> Then you'd have to essentially build the linker into the compiler.

Ah.. I'd have thought using 'import' as you currently do was the same sort of thing, but I guess I don't know enough about how compilers work :)

The thing that suddenly seemed odd to me, and the reason I wanted to see how C# did it was the fact that you're using 'import' to determine whether/when something needs to be initialised, when in fact 'import' doesn't guarantee the thing is actually used at all.

I can import something erroneously into a module, then never actually use anything in that module, or, use only one pure function that doesn't use the static needs-to-be-initialised data.

Using 'import' is always going to produce more false positives, but I guess it also cannot produce a false negative.

R




1 2
Next ›   Last »