John Nagle: > All signed Windows 7 drivers must pass Microsoft's static checker, > which checks that they don't have bad pointers and call all the > driver APIs correctly.
I didn't know this, thank you. I'll read more about this topic. ---------------- Eric S. Johansson: > If you are careless, assertions can build up to a > significant percentage of the code base and Slow execution. the argument for > dealing with this, last time I looked, was that you turn off assertions when > your code is "running". This logic is flawed because bugs exist and will > assert > themselves at the worst possible time which usually means after you turned off > the assertions. These are real problems. In some situations the code is "fast enough" even with those runtime tests, so in those situations it's better to keep them active even in release builds or when you use the program (this is often true for small script-like programs). But in some situations you want a faster final program. Running the run-time contracts only when you test the code and removing them when you run the program for real sounds silly or dangerous. But life is made of trade-offs, and running those contracts during testing is better than _never_ running them. In practice if your tests are done well enough (they are similar to the real usage of the program), the contracts are able to catch most of the bugs anyway before the release build. The run-time contracts may slow down the code, but there are few ways to reduce this problem. You have to write your contracts taking care of not changing the computational complexity of the routine/method they guard (so you usually don't want to perform a O(n) test for a routine with O(n ln n) worst-case complexity). You run your tests often, so if some tests are too much slow you see it soon and you may fix the problem (the same is true for slow unit tests). In D there are several ways to "layer" the work you perform at runtime, there is not just the release build and test build. You have the version and debug statements, you may use them inside DbC contracts too. So in normal test builds I use faster contracts, but if I spot a bug I lower the debug level and I recompile the D code, activating heavier tests, to better spot where the bug is. One good thing of DbC is that when the "density" of presence of contracts in your programs gets higher of some threshold, most of the bugs present in the code show themselves up as failed assertions/contracts. To me it seems related to percolation theory :-) (http://en.wikipedia.org/ wiki/Percolation_threshold ). In D you may also use enforce(), that's essentially a camouflaged throw/raise statement, if you use it outside DbC contracts, they are tests that run even in release builds when your contracts are disabled. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
