Debugging

I often still debug via printf. Or, rather, via other code that eventually calls printf. I used to feel guilty about this, embarassed that I did not always use a debugger like gdb. But then I heard some famous programmers say "I debug using printf".

Even better, since I started doing Agile, I spend less and less time debugging. (Conversely, when I work with legacy code, code that doesn't have tests, I spend more time debugging.) 

Now, I have gotten better at using debuggers like gdb over the years. And some of my "add code" debugging cooperates well with debuggers like gdb.

For example, many many years ago another student/lab manager/research assistant/TA (who I think is reading this blog - thanks, Steve) said that he was in the habit of writing data structure printing tools and consistency checks, even if not used in his "production" code - if for no other reason than to be able to call them from a debugger. To this I add that such code is often also useful in automated unit tests. (Diffing taking into account hex addresses...) And also useful if you have to fallback to printf debugging.

What I like about printf debugging is that it often develops assets, code that can be reused.  Both for future debugging, and for other purposes.

Whereas gdb style debugging often does not.  Yes, you can write debug scripts - e.g. I found some useful scripts that can dump STL datastructures in a nice manner, rather than in the unreadable manner that so many debuggers print them.  So-called symbolic, but not very high level.

assert/ignore pattern

Here's a pattern I observed today. I have seen it before. (In my wont to record neat little tidbits that m,ay be worthy of further thought.) Started with code:

    Object* objptr = ...;
    assert( objptr->consistency_check() );
    assert( objptr->fooptr->consistency_check() );
    assert( more_consistency_checks(objptr) );
    ... do something with objptr ...

Now, often enough it might be correct not to error exit with an assert. Often enough, in my problem domain, if one of the consistency checks fails you can just ignore the object, and go on. In my domain, computer architecture, this may arise because of speculative execution. So, pseudo-equivalent code might look like

    Object* objptr = ...;
    
    if( ! objptr->consistency_check() ) {
    }
    else if( ! objptr->fooptr->consistency_check() ) {
    }
    else if( ! more_consistency_checks(objptr) ) {
        ... do something with objptr ...
    }

I know, you might prefer

    Object* objptr = ...;
    
    if( objptr->consistency_check()
        && objptr->fooptr->consistency_check() 
        && more_consistency_checks(objptr) ) ) 
    {
        ... do something with objptr ...
    }

but I have found that I often want to do stuff like keep stats for which forms of inconsistencies were found, i.e. which assert would have failed if we had been failing. Or

    Object* objptr = ...;
    try {
      assert( objptr->consistency_check() );
      assert( objptr->fooptr->consistency_check() );
      assert( more_consistency_checks(objptr) );
      ... do something with objptr ...
    } catch(...) {
      ...
    }

although it can be unfortunate if the catch is a long way away from the assert. You might want to specify the assert fail action at the assert - which is what the OF statements do. --- No biggy, just a pattern I have seen before.