Date: Mon, 18 Dec 2000 13:11:12 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <20001218131112.B65143@hamlet.nectar.com> In-Reply-To: <200012181840.LAA92561@harmony.village.org>; from imp@village.org on Mon, Dec 18, 2000 at 11:40:43AM -0700 References: <20001217151509.A63051@hamlet.nectar.com> <20001217151735.D54486@holly.calldei.com> <20001217153129.B63080@hamlet.nectar.com> <20001217153656.F54486@holly.calldei.com> <20001217155648.C63080@hamlet.nectar.com> <20001217160442.H54486@holly.calldei.com> <20001217170316.A63227@hamlet.nectar.com> <200012180501.WAA87838@harmony.village.org> <20001218123108.A65143@hamlet.nectar.com> <200012181840.LAA92561@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 18, 2000 at 11:40:43AM -0700, Warner Losh wrote:
> In message <20001218123108.A65143@hamlet.nectar.com> "Jacques A. Vidrine" writes:
> : None taken. It is however a simple and safe optimization, with no
> : apparent downsides. It has the same attraction as using bit shifts
> : instead of multiplication/division, or saving the value from a function
> : call that will be needed again later, even if you know the function call
> : is trivial.
>
> You are trading a test against zero and code obfuscation against a
> function call. The function call is typically much less than even a
> multiplication or division would be. You get clearer, easier to read
> code that is smaller by allowing free to do its job and not trying to
> optimize things.
Ever notice that you tend to send more email when you should be studying
for a final?
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
I don't see that Case 1 obfuscates anything. In some cases I find it
clearer: Case 1 implies that maybe no memory was allocated. Case 2
seems to imply that memory was indeed allocated.
> I guess I tend to think 'This needs to be freed, let free deal with
> the details so I won't have to be bothered with them.' Function
> abstraction is supposed to be about hiding details that don't matter.
> And in my opinion, this is one of those details.
I think it depends on the context.
> I've also seen code written where this sort of thing was taken to an
> obscene degree where you'd have 10-30 layers all making the same
> validity tests to ensure the data was really really good when it was
> impossible to get down more than a layer or two and have it be bad.
> Before you say that more tests are good, I cleaned up this mess and
> was able to reduce 5 overlay regions (yes, 5!) on a pdp-11 fortran
> monster due to systematically eliminating them (well, I ifdef'd them
> out (we wrote a fortran preprocessor, but that's another story)). The
> code went from something like 500k to 225k by removing the redundant
> tests through all the layers. I know this is an extreme example, but
> it does go to show that sometimes these tests can be rather
> signficicant.
I agree with what you are saying, and yes, it is an extreme example. I
guess I was focused on the particular case of free().
I happy with the opinions I've received. Based on them, I seem to be in
the minority of preferring `if (data) free(data);' in some cases. OTOH,
our code base speaks differently than the email I've received -- `if
(data) free(data);' seems to be used quite alot. I will probably
continue to use it the way I have before -- to make it clear that there
may or may not be memory to free at this point.
Cheers,
--
Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001218131112.B65143>