jeff@aiai.ed.ac.uk (Jeff Dalton) (01/23/91)
In article <106389@cc.utah.edu> RCAPENER@cc.utah.edu writes: >In article <3954@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > >Oh no! Here we go again... It is bad enough for FORTRAN users >to mistake C's libraries to be the same thing as FORTRAN's, and >Ada/Pascal/Modula-2 folks to mistake the C header files for the >being the same thing as Pascal's {INCLUDE ....} directives. But >as fellow functional language advocates, I expect LISPers to know >better. Sigh. I was assuming that in this newsgroup I wouldn't have to spell out every detail and wouldn't have to explain everything at length just to prove I knew what I was talking about. I also expected people to try to interpret my statements as true ones before concluding that they must be false. >> If we start with C and >> then add in various libraries, it starts to look fairly large too. And indeed it does start to look large. Common Lisp looks big because, for one thing, there are over 700 functions in it. The while point of my message was that (1) if more of the C libraries were considered part of the language it would start to look big just as CL does, and (2) if CL were implemented more like C, it's size wouldn't be such a burden in practice. But for some reason, you have decided that I think all the C libraries might be included in every a.out: >In C, you do not add in the libraries. You add in ONLY those >functions from that library that you requested. Not quite. You get the ones you call plus the whatever they call and so on. Moreover, Lisp could be implemented in a similar way. Indeed, some implementations are moving in that direction. But they work by throwing out what's not needed rather than by putting in only what is. There's nothing to stop them from doing it the other way, though. >> In addition, constructs with related functionality (a data type and >> procedures for operating on its instances, for example) are often >> packaged together in a module. If your program makes use of such >> facilities, you must request the appropriate module, just as you must >> include the appropriate ".h" file in C. Note: this is what we call an anology. I am not saying "header files _are_ modules". Nor am I assuming the header files contain the code. The header file (used in a certain rather common way) is analogous to an interface description. If you want to use the stdio library, for example, you will (usually) #include <stdio.h>. I assumed that this was common knowledge. Guess not. >You do not have to #include the header file, Depends on whether you want to write the declarations yourself or not. >and a header file is NOT a module. See above. > All header files contain (at least system header files) >are type definitions, Or at least that is all they SHOULD contain. Actually, header files can include anything you want. However there are certain conventions ... And system header files contain declarations (not just type definitions) and macro definitions. > I cringe every time I am >reminded of a teacher at a University (who shall remain unnamed) telling >his students to write code they use over and over and put it in a header >file! This is NOT the way to write C! For example, the following is a >legitimate C program, and note, not one header file. I hope you don't think it's good practice to not, for example, include stdio.h when using stdio. >Hope this clears up ANY confusion about the language C. Personally, >I like both LISP and C, so please don't flame me. Well, sorry, but I couldn't let so complete a misunderstanding go uncorrected and a flame is what came out. -- jeff
markf@zurich.ai.mit.edu (Mark Friedman) (01/23/91)
In article <106389@cc.utah.edu> RCAPENER@cc.utah.edu writes:
In C, you do not add in the libraries. You add in ONLY those
functions from that library that you requested. For example,
if you have the log() function in your code, the -lm directive
to the link loader extracts only the log() function, not every
function in the library! In other words, you pay for only what
you need, no more. I would say that most C executable programs
are 1/2 the size of a LISP program (including the overhead of the
LISP system) for any moderately large system.
This generally not the case for C linkers. Usually the entire object
module containing the function that you need is extracted from the
library and linked into your executable. Run nm (which lists external
symbol names) on your executable and you'll see what I mean. I would
have included the output from nm on your small test program in this
message, but it was 209 lines long :-)
Hope this clears up ANY confusion about the language C. Personally,
I like both LISP and C, so please don't flame me.
Hope this clears up ANY confusion about the language C. Personally, I
like both LISP and Scheme, so please don't flame me :-)
-Mark
--
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
markf@zurich.ai.mit.edu