Author: Robert Hyatt
Date: 10:31:40 11/04/02
Go up one level in this thread
On November 04, 2002 at 12:10:07, Miguel A. Ballicora wrote: >On November 04, 2002 at 09:39:14, Vincent Diepeveen wrote: > >>On November 04, 2002 at 06:40:14, Pham Minh Tri wrote: >> >> >>I hardly use asserts in DIEP. If i need one i usually use a >>printf, which gets removed using a // when it is tested well >>and a year later or so removed. >> >>I guess bob has the same habit. > >Interesting. >For Uri: do use asserts!. It is important not to copy the bad habits of talented >programmers. >Good habits are for us, mortals, and they work. > >Miguel I don't consider an assert() as "good" or "bad". It is just _one_ tool you can use. But it doesn't provide enough information, in general. I have some code that does much more than a simple assert, so that I can call it where it is needed and it provides a lot of information about what is wrong and the circumstances when it goes wrong. I do use asserts when appropriate. I use other things as well. Don't become "the man with a hammer who thinks everything therefore looks like a nail..." Different tools for different circumstances is a sign of flexibility, it is _far_ from a "bad habit". > >>I boundscheck carefully though and if i detect a difference in >>node count somewhere then i am going to check it out and do not >>ignore it or claim the compiler is to blame :) >> >>Note that it is a hard truth that compilers *do* make errors, >>but in 99.99% of the cases it is a bug in the program, so finding >>them happens very seldom. Basically i just found out some stupid >>things in gcc and in intel c++. >> >>Best regards, >>Vincent >> >>>On November 03, 2002 at 13:47:57, Vincent Diepeveen wrote: >>> >>>>On November 03, 2002 at 12:23:50, Russell Reagan wrote: >>>> >>>>Do you have an assert for every index in your program? >>>> >>>>If not then a boundschecker might be an idea to try as well :) >>>> >>>>>What I usually do to find bugs is use the assert() macro (in assert.h, or you >>>>>could write your own). Basically what you do is you assert things you know >>>>>should be true, such as an index into an array being in bounds. If it's false, >>>>>your program will halt and let you know where the error occured. For example: >>>>> >>>>>assert(i < MAX_VALUE); >>>>>myArray[i] = SomeFunction(x); >>>>> >>>>>That way, when you run the program, it will make sure that i is within bounds. >>>>>The cool thing about this is that it only does this in debug mode. In release >>>>>mode the assert()'s go away, so there is no speed penalty. In my programs I go >>>>>crazy with asserts, and put them all over the place, and it helps find some bugs >>>>>I wouldn't have found without the asserts. Yes, it will run slower in debug >>>>>mode, but the point of debug mode is to find bugs, not to run fast. >>>>> >>>>>Russell >>> >>>I agree that use of asserts in everywhere is one of the best experiences to >>>share (including check bounds). Sometimes my new changes can trigger some dozens >>>of asserts. Without asserts, my program can run two times slower in debug mode, >>>but now, it is 20-30 times (in term of nodes per second) as slow as it in >>>release mode. The big benefit is I can fast develop program, try many new ideas >>>without worrying much about new errors. >>> >>>One of amazing thing to me is that I don't find out asserts in Crafty. So I >>>guess Bob used a special program to clean up the developing versions before >>>releasing. >>>Bob, is it correct? Thanks :)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.