suggestion for auto breakpoints

[Duane Voth]

jbb wrote:
> 
> On Wed, 02 Feb 2000, you wrote:
> > A useful way to debug new programs is to place a break point
> > inside each function and even inside each if/else and switch
> > statement.
> 
> This would be too much work, and I doubt that you'll use this feature,
> especially as the complexity of your app increases. Finding all the places to
> set breakpoints would require parsing your source, and I don't want the
> debugger to be involved in that.

I agree the debugger should not do it.  "some" part of kdevelop however
already does parse the source (to create the list of functions). 
Creating
a list of tags for complete breakpoint coverage here should be pretty
straight forward.?

> In a medium size app, written by a team of
> people, you could easily be looking at a few thousand breakpoints. A
> daunting task for a single person to check every path.

Yes, as is ensuring that each code path is debugged - or even gets
executed.  With a list of these breakpoints which are persistent
across invocations of kdevelop, the team would, after a group debug
effort, be left with a list of places where execution never, or
rarely occurs.  These are the places most prone to bugs.

> There is a way for you to do this now, but it involves you writing some code.

I was hoping for some automation help.  ;)

And the code verification people might all be beside themselves with
interest.

> Add a debug function which calls another function that is called only once
> per run and set the breakpoint on this. Then sprinkle the debug calls throughout
> your program.

.. with one flag per debug call..  which is what a breakpoint is.

> If, after "prototyping" this functionality in your app, you still feel it's
> valuable then perhaps I could be persuaded.

Well let's keep it out of the debugger and see if the code parser folks
are interested.  This may help solve their current "sliding breakpoints"
bug too.

duane