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

Geoffrey esoteric at 3times25.net
Sat Sep 25 08:29:45 EDT 2004


John Mills wrote:
> Barry -
> 
> Thanks for the input.
> 
> On Fri, 24 Sep 2004, Barry Rountree wrote:
> 
> 
>>On Friday 24 September 2004 08:41 pm, John Mills wrote:
>>
>>>Naturally, I got a bit too clever 
> 
>  
> 
>>It's almost certainly going to be easier to rewrite it as something less 
>>clever, but hey, where's the fun in that?
> 
> 
> 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 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.

1. unknown number of slots needed - dynamic slot allocation.
2. finite number of slots needed - static slot allocation.

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



More information about the Ale mailing list