View mode: basic / threaded / horizontal-split · Log in · Help
March 16, 2010
Re: order of static constructor execution
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
Re: order of static constructor execution
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
Re: order of static constructor execution
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home