I use VC++ 2008, and I do so specially for it's debugging capabilities. I could of course use printf and find the problems, but it takes some time and have to be careful to remove them or use stderr.
It is also true you can only find problems in the algorithm you chose, but I usually spend enough time with paper and pencil, so when I start to code I'm almost sure the algorithm choice is correct, so I only need to find bugs in it. Sometimes I debug a solution, hit a crash state for some reason, I modify the value of a variable and the fix buggy code from within the debugger and keep running the same application instance. If after that I got correct solutions, then the code was debugged as opposed to only found. But that's for me, what I'm 100% sure, is that the best environment is the one you feel most comfortable in. The problem is that you should try several environments, from full blown IDEs to lightweight text editors + command line compiling. And see what fits you, not all humans like the same thing, and no one knows which is the best choice for you. Try them all and find the best for you. Carlos Guía On Tue, May 25, 2010 at 10:16 AM, Ken Corbin <[email protected]> wrote: > I write programs for a living, and in the real world a good debugger is > essential. But I have found them surprisingly unhelpful to GCJ style > programming contests. In the real world, most code problems seem to occur > in > large complicated chunks of code that are executed 1 to maybe 5 times. In > programming contests there is a lot less code, but those lines are > typically > run from anywhere to hundreds to tens of thousands of times. Debuggers can > be used in that environment, but it gets a lot harder and is generally > easier > to fall back on the time honored debugging technique of just adding print > statements. > > On Tuesday 25 May 2010 06:55:42 Amtep wrote: > > On Tue, May 25, 2010 at 06:04:04PM +0530, Dhruva Sagar wrote: > > > But the real reason I think that to be the case is because Debugging > will > > > not help you get the right algorithm, it will only help you find > problems > > > in the algorithm you thought of... > > > > But that does help you find the right algorithm :) > > During the contest I often choose a simpler algorithm that's less > efficient > > but which will save me on debugging and programming time. > > If I had a faster way of debugging, then I could also choose more > > complicated algorithms. > > > > I'm not sure if I actually would, though. It's not just a matter of time. > > There is also the risk that a mistake in the code makes you get the > 'large' > > input wrong. So I usually keep things simple. > > > > (Often the faster algorithm is also simpler, but not always!) > > > > -- > > Richard Braakman > > > > -- > You received this message because you are subscribed to the Google Groups > "google-codejam" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-code%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-code?hl=en. > > -- You received this message because you are subscribed to the Google Groups "google-codejam" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-code?hl=en.
