[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