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

[Geoffrey]

John Mills wrote:
> 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.

Ah, wanting to learn another hard lesson. :)

>>>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.

:)

-- 
Until later, Geoffrey       Registered Linux User #108567
                             AT&T Certified UNIX System Programmer - 1995