On Mon, 3 May 2010, Steve Schveighoffer wrote: > ----- Original Message ---- > > From: Walter Bright <[email protected]> > > > > I'm reluctant to transform > > all asserts because: > > > > 1. this means all asserts, whether meant for unit > > testing or not, have to have return code, negatively affecting optimization > > all > > the time > > > > 2. many asserts are not meant at all to be unit tests, and > > there's no reason to think otherwise when they are outside the unittest > > block > > We're forgetting 2 things here: > > 1. unit tests run independently of any user input, they are completely > defined by the unit test code itself. > > 2. Nobody, and I mean nobody, should ever compile unittest code for > production. In fact, I'd say you probably have not understood the meaning of > unit tests if your main function looks anything unlike: > > void main() {} > > Therefore, you shouldn't be concerned with the optimization quality of > unittest code during asserts. > > What if we solve this with a completely global solution -- when compiling > with unit tests enabled, all asserts do a unittest style assert (decided at > link), when compiling without unittests, asserts function as they do now. > Can this be done? > > -Steve
Careful.. don't conflate building unittests into production code with building production code with asserts enabled or disabled. I run LOTS of important code with asserts enabled in production. I'm willing, in fact eager, to risk a production system exiting rather than it continuing to run past an assertable state. I will say that there's a set of asserts that I do disable in production systems, those that are really expensive to execute -- most of mine are dead trivial. Admitedly, I'm not talking about D here, but rather C++. But the philosophy doesn't differ based on language choice. I fully agree that with D that it's unlikely that I'd leave unit tests turned on in production builds -- but if the tests are fast enough to leave in, no real harm either. Keep in mind, they don't affect anything beyond the cost of app startup, or shouldn't. Later, Brad _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
