[ale] C++ Debuggery and the Path of Destruction

[John Mills]

Geoffrey, All -

On Sat, 25 Sep 2004, Geoffrey wrote:

> > Yes, well there is that aspect. I've been at this long enough to know I'm 
> > creating a maintenance headache, though, and less clever would be smarter.
 
> John, really, those are scary words in a development situation. 
> 'maintenance headache.'  Should you not look at a cleaner approach?

The short and correct answer is 'Yes.' There are designs fraught with 
potholes and booby traps, and this looks like one of them.

My worst debugging and maintenance problems have come from constructs that
were over-clever and conflictingly used in multiple parts of the code. Now 
I shy away from that, but my instincts slipped-up on me.

> > The ostensible reason is I am allocating image buffers that are passed on
> > to an unknown number of asynchronous clients. I store them in a ring that
> > [hopefully] has enough slots so even a slow client will have time to send
> > the newest buffer before it is trashed in favor of a yet newer image (4 or
> > 5 down the line). That code is very simple and works fine. The alternative
> > seemed to be copying each buffer for each client to which it's due, which
> > I wanted to avoid.
 
> Wow, some more scary statements.  '[hopefully] has enough slots' 
> Really, you should insure that you have enough.  One of two solutions, 
> depending on the problem.
 ...
 I do this:
> 2. finite number of slots needed - static slot allocation.

The number of slots is fixed by a compilation constant.  There are tests
to harmlessly catch an overrun on the ring.

Each slot points to a dynamically allocated byte buffer for whatever size
image has been returned on that round. These are what I tried not to
recopy. I ended up with a mix of local and remote buffer allocations,
which is just a _REAL_Bad_Idea(TM)_; it's going to go, NOW.

 - John Mills
   john.m.mills at alum.mit.edu