Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!ll-xn!ames!oliveb!pyramid!prls!philabs!sbcs!bnlux0!drs
From: drs@bnlux0.bnl.gov (David R. Stampf)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <474@bnlux0.bnl.gov>
Date: 25 Apr 88 01:04:27 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA>
Reply-To: drs@bnlux0.UUCP (David R. Stampf)
Organization: Brookhaven National Lab., Upton, N.Y.
Lines: 36

In article <7750@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <154@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>>When portability is not an issue, a programmer should be free to use
>>his or her own implementation of a standard library function.
>
>I think you need to explain why this is considered desirable.
>
>Many of the library functions are likely to have secret internal
>interfaces to others, so you cannot implement them correctly in a
>portable application.  Others, such as strcpy(), will be implemented
>more efficiently in general in the standard library than in your
>application.  If you try to speed them up by providing subset
>functionality, you may break other library routines that need to use
>these with full functionality.
>

Even when portability is and issue - I think that the C view of libraries
is meant to be taken advantage of!

I have frequently found the need to chuck some of the standard library
routines in favour of locally written routines - more often that not, these
are the memory allocation routines.  Sometimes it is to gain a *huge*
performance gain (in one example I didn't need the full generality that malloc
gave me, since I was always allocating fixed length blocks, so I wrote my own
that took advantage of the machine that I was running on (Mac) and other times
it is to take advantage of some unique aspect of the machine that I was working
on (parallel processing with shared memory).  In either case, I wanted the
code to be portable to { wide variety of machines that may have very different
architectures.  Those machines may pay a performance penalty, but not the
ultimate penalty of having to rewrite bizarre library routines.

In these cases, you cannot export your custom library routines - but have to
allow the default library to kick in.  (It also makes debugging a *lot*
easier in most cases).

	< dave.