www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - code coverage and module constructors

reply BCS <BCS pathlink.com> writes:
	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?
Jun 19 2006
parent reply kris <foo bar.com> writes:
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?
Jun 19 2006
parent reply BCS <BCS pathlink.com> writes:
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?
Jun 19 2006
parent kris <foo bar.com> writes:
BCS wrote:
 kris wrote:
[snip]
 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?
Well, my little gripe with cyclic imports is that they tend to tighly-couple implementation details. That's very much a design-dependent measure, so it's a bit airy fairy for most purposes. For example, some designs are intended to be tightly-coupled. One the other hand, there's something to be said for a large body of code that can be cleanly represented as a DAG (no cycles). Tends to make the overall system a whole lot easier to extend, easier to decouple as necessary, and so on. I suppose it's all about maintenance? Maybe a whiff of 'elegance'? Maybe not. [snip]
 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.
Yeah ... in my case, I had to get a fairly substantial library working with -cov, since it would seem rather bogus for a lib to conflict in that respect. Don't want to get off topic too much, but I found Dimple to be a true bobsend for visualizing import-relationships over a large (200+) swathe of modules. I've also discovered that attempts to make the diagrams look 'cleaner' (through refactoring) have an equally pleasant effect on the codebase design itself :)
Jun 19 2006