On Thu, Apr 18, 2002 at 07:55:15AM +0200, Mike Nordell wrote: > Patrick Lam wrote: > > > Something like UT_ASSERT(pNext != NULL); would be a useful assert, as > opposed > > to UT_ASSERT(b == true || b == false); > > For any other project I'd agree. Actually, I'd probably enforce that's the > only places to use it. However, for AW I've had to modify that standpoint > since I both found the artifical bool we earlier used to be uninitialized, > and I'd like to see the real C++ bool I've now managed to get into the code > to also be enforced to be initialized, and this is disregarding a memory > checker like Valgrind, BoundsChecker, Purify or whatever it might be. If > it's possible for us to catch it in code I'd prefer it rather than to > _depend_ upon some third-party library, especially since we _can_ check it > ourselves. The earlier an error is found the easier it's corrected.
C++ sucks this way. I much prefer Java disallowing uninitialized variables. It's not rocket science. In any case, we don't check asserts in non-debug builds. So I don't think that this wins us too much over running in Valgrind or whatever as necessary. We can't check it ourselves exhaustively (and that would make the code suck) anyway. I mean, if you remember to assert, then you've probably already remembered to initialize. > What about starting with checking parameters (like preconditions) and return > values (like post condition)? That should add no cruft interfering with the > understanding of the real code (even that I think you are wrong in opposing > checkning stuff inside a function). I'm all for checking preconditions and postconditions. They are helpful, but not a panacea. Actually -- I'd much rather have documentation about preconditions and postconditions as a first step (not that asserts are bad). A lot of our functions don't have a documented interface, and that sucks. I don't oppose checking things inside a function, but the things should be well-thought-out as opposed to UT_ASSERT(true||false). pat
