code coverage and module constructors

[kris]

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?


Yeah .... -cov simply highlights the problem if cyclic imports with 
static-ctors; simply becuase -cov injects a static-ctor into each module 
(or something like that).

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. 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. However, I suspect the end-result of my effort 
was worth it.

Hope that doesn't muddy the waters too much?