Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!cbnewse!cwpjr
From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips)
Newsgroups: comp.lang.forth
Subject: Re: Size of C
Summary: So you do what we do in FORTH
Message-ID: <1991Jan10.172839.14614@cbnewse.att.com>
Date: 10 Jan 91 17:28:39 GMT
References: <9101100302.AA08161@ucbvax.Berkeley.EDU>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 32

In article <9101100302.AA08161@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes:
> > > Printf() is notorious for including a lot of formatting code. ...
> 
> Most C implementations only include the library routines that are
> actually used.  The problem with printf() is that it is supposed to be
> able to handle a variety of different number types, including floating
> point numbers.  The determination of which format to use at any given
> time is made by a string argument that can be constructed at run time.
> Therefore, the linker usually does not know whether or not the floating
> point libraries are going be be needed or not, and the implementor often
> chooses to err in the safe direction.
> 
> In the C "wrapper" programs that I use for interfacing Forth to various
> operating systems, I avoid printf(), instead using puts().  If I need to
> display numbers, I write my own "puti()" routine.

All this says is that efficiently coded ( sizewise ) "C" is nonstandard.
What good is a standard "C"? About as good as a standard FORTH!

> 
> The trend in operating systems is going toward shared libraries, so the
> size of printf() is beginning to cease to matter, as a single copy of the
> library is shared among all the processes in the system.

Isn't this the essence of a well factored FORTH? The basis for shared code
is adequate factoring to allow all "custom" versions to utilize the most
standard words/subroutines?

> 
> Mitch

--Clyde