Error freeing bug made me think "what's the point?"
in [Unix Programming]
|
From: Golden California Girls on 21 Feb 2010 23:28 Rainer Weikusat wrote: > > Code which is written such that it solves a particular problem today > can be reused for something different tomorrow without implementing > the support for 'something different' already today, "just in case". > It doesn't buy anyone anything to write some code 'today' which is > 'today' useless and actually even detrimental because this code > _might_ be of use at some unspecified point in time in the future. > The code necessary to do Y can be written whenever the need to do Y > actually materializes. For as long as it hasn't, the chance that Y > never needs to be done is greater than zero and in this case, all that > has happened is that human has wasted some of his time to implement > something which requires any 'user' of the code (not 'developer') to > also waste some of his time by wasting some of the computing resources > available to him. Work more to achieve less, so to say. We can see who is management and who is union.
From: David Schwartz on 22 Feb 2010 01:02 On Feb 21, 1:00 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > The basic meaning of this statement is "do useless work now in order > to make the computer do useless work forver because it might be useful > in future". And my take on this would usually be "don't do the useless > work now, but do it also 'in future'". The point of 'free' is to > inform the malloc allocator that a particular chunk of memory isn't > needed anymore and can thus be reused to satisfy some future > allocation request (simplification). If there won't be any future > allocation requests, calling 'free' is a pointless exercise. I think there's truth in both sides of this argument. One counter- point to Rainer's point is that it can be much easier to write the code now than it will be to try to graft it on later. If code is designed to throw away pointers in lots of ugly little places, it can be awfully tricky to track them all down later. A classic example is a function that sometimes returns a pointer to a static string and sometimes returns the value from 'strdup'. You may throw these things in now because "this isn't a long-lived program anyway", and they can be so hard to track down and clean up later that it means your code *can't* be re-purposed. In any real-world case, you have to balance these three factors: 1) How hard is it to make my code clean up after itself? 2) How likely is it that I'll ever need to use this code in a case where it matters whether it cleans up after itself or not? 3) How much risk will I be adding that my clean up code will introduce bugs or issues? DS
From: Rainer Weikusat on 22 Feb 2010 05:03
Golden California Girls <gldncagrls(a)aol.com.mil> writes: > Rainer Weikusat wrote: >> >> Code which is written such that it solves a particular problem today >> can be reused for something different tomorrow without implementing >> the support for 'something different' already today, "just in case". >> It doesn't buy anyone anything to write some code 'today' which is >> 'today' useless and actually even detrimental because this code >> _might_ be of use at some unspecified point in time in the future. >> The code necessary to do Y can be written whenever the need to do Y >> actually materializes. For as long as it hasn't, the chance that Y >> never needs to be done is greater than zero and in this case, all that >> has happened is that human has wasted some of his time to implement >> something which requires any 'user' of the code (not 'developer') to >> also waste some of his time by wasting some of the computing resources >> available to him. Work more to achieve less, so to say. > > We can see who is management and who is union. ? |