code coverage and module constructors

BCS BCS at pathlink.com
Mon Jun 19 16:19:29 PDT 2006


kris wrote:
> BCS wrote:
> 
>>     If two modules mutually import each other, you can't use code 
>> coverage on both of them. This is (I think) because the code coverage 
>> is implemented with some sort of module constructor and generate a 
>> loop (static this in mod-a must be run before the static this in mod-b 
>> which must be run before the static this in mod-a ...).
>>
>>     However this is bunk, -cov for one module shouldn't have any 
>> dependencies on any other module. D already has one case where a 
>> module constructor like thing is use that doesn't care about circular 
>> imports, unittests. Why then isn't the cov startup run the same way?
> 
> 
> 
> On the other hand, cyclic imports are kinda "poor form" - for want of a 
> better description. You *can* eliminate them, potentially using an 
> interface as an intermediary; and probably *should* eliminate them.

Why are they poor form? (This is a non-rhetorical question, I would like 
to hear your reasoning.) Putting all your types off by them selves in 
there own modules can help some. But what about, say, a pair of structs 
that have methods that take each other as arguments but otherwise have 
no reason to be in the same module?
e.g.
struct foo
{
	...
	void UseBar(bar b){...}
}

struct bar
{
	...
	void UseFoo(foo f){...}
}

And interfaces cause a bit of a performance hit (they are bigger for 
one). Even if this can be eliminated in most cases. Sooner or later it 
won't be practical or desirable to do it. I would list this as a high 
priority item on the to list, right below getting -cov working.

 > Of
> course, that doesn't help when there's cyclic imports all over the 
> library code that one happens to be using (the Win32 headers?).
> 
> I understand where you're coming from on this, and wholly sympathise 
> since I recently had to redesign a few substantial chunks of code to 
> eliminate the problem. 

<nods> I've just lived without static constructors some times.

 > However, I suspect the end-result of my effort was worth it.
> 
> Hope that doesn't muddy the waters too much?



More information about the Digitalmars-d-learn mailing list