🚀 go-pugleaf

In article <1992Nov3.130634.26112@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
>|> In article <1992Nov2.083810.1652@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
>|> >jch@rdg.dec.com (John Haxby) writes:
>|> 
>|> >>C's pointers are a pain in the neck sometimes.
>|> 
>|> >Great understatement :-) You simply don't need C style pointers in decent
>|> >programming languages.
>
>C's pointers don't actually provide anything useful, apart from,
>perhaps, an ability to duplicate Lindsay's `triple ref' code.

Sure they do.  Pointers are not just variables, they're polymorphic 
placeholders.  When you want an identifier that can be an integer, 
a function, or a port, you use a pointer.  You want to return a 
function from a function?  You can do it in C -- you return a pointer.  
You want to define your own objects (or packages) with member functions, 
you can do it with structures and pointers.

>
>If one thinks in terms of references to objects and elements of arrays
>rather than pointers to both, things become somewhat clearer.  C's
>pointers-as-references are not all that different from Algol68's except
>in syntax and an explicit `address-of' operator.  Where you do get
>some significant differences is in arrays and storage management.

Simple enough.  C has arrays.  Use _them_ rather than pointers when they
make your code easier to understand.  Pointers make poor arrays.  Don't
misuse them simply because you can.  

An anvil makes a poor hammer, but that doesn't mean you should throw
away the anvil.

>
>Algol68 is still way ahead of C in this game.  Array members and
>references may compile to much the same code, but in the language they
>are treated quite differently.  The need for pointer arithmetic (that C
>provides) simply does not arise 
[...]

C doesn't require pointer math, it avails you of it.  Don't use it if
you dislike it.  As you've said, ponter math isn't necessary in a PL.
However, it can be an advantage in many cases of low-level implementation,
like when you need to roll your own array (as in using malloc() to 
produce dynamic arrays at runtime).

The nice thing about C's low level programming support is that you 
don't have to tolerate the imposition and girth of a garbage collector 
(something that belongs in a library anyway).  If you really want one, 
once again, C will let you roll your own.  But you're not stuck with one.

>[...]
>Generates no extra code for the bounds checking.  The cases where
>the bounds checking finds bugs in the program, before the bug tramples
>over all the outlying data, are, of course, immensely valuable.  

If you want run-time error checking, then C is the wrong choice of
programming language for a lot of better reasons than array bounds 
checking.

>Yes, I know about the various tools for checking for this sort of thing, 

Yes.  Like lint.  

>but if I learn to swim with armbands, does that mean I can forsake 
>them and swim to France? (to paraphrase Dijkstra, I think).

Isn't this a bit like saying "once you've learned language X you should
continue to program in it exclusively" even if the language is inefficient, 
its features wasteful and often unnecessary?  Sure, Lisp is great for
rapid prototyping, but why choose it to write an operating system?  
Likewise, C is great for low to mid-level programming tasks.  It doesn't
excel at those which require fault tolerance or rapid prototyping.
However, due to its utility and ubiquity, its popularity and wide-spread
use cannot be discounted either.  Sometimes C is used just because it
_can_ do the job and serve more than one master.

As always, choose the tool that does the job best.

-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102