NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/misc/3547

Text File | 1992-11-09 | 6.7 KB | 129 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!munnari.oz.au!metro!usage!syacus!ian
From: [e-mail] (Ian Joyner)
Subject: Re: Pointers
Message-ID: <[e-mail]>
Organization: ACUS Australian Centre for Unisys Software, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 7 Nov 1992 11:56:20 GMT
Lines: 118

[e-mail] (Randy Crawford) writes:

>In article <[e-mail]> [e-mail] (John Haxby) writes:
>>|> In article <[e-mail]> [e-mail] (Ian Joyner) writes:
>>|> >[e-mail] (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.

OK, saying pointers don't provide anything useful was taking it a little
too far. What you are describing, however, is situations where you want
to crack a peanut with a sledge hammer. The use as polymorphic place
holders is definately sledge hammer technology. It grinds type safety into
a fine paste on the concrete which is not suitable for consumption. Somebody,
somewhere said that when you have a hammer, every problem looks like a nail.

>>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.

The point (sorry for the pun) being made is that pointers are a low level
implementation for references. C lacks references, by-reference parameters,
procedure references, etc. Thus in C everything looks like a nail, and the
one solution is to use the pointer hammer. To make the distinction a little
clearer, references bind to entities. You do not care how they bind to an
entity. C pointers, however, make it clear that the binding is accomplished
by a low level machine address. This is a very architecture dependent
thing.

>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.

Now that's the idea, let's all reinvent the wheel from scratch. This
comment on garbage collectors is wrong and ill informed. A garbage
collector certainly doesn't belong in a library. It is a run time
environment concept. Garbage collection is 'how' things are done, so
the programmer should not be burdened with this level. The correct
concession is to allow garbage collection to be disabled.

>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.

Now we are getting somewhere. What you have just said makes C a wrong
choice full stop. If an error occurs in a computation, then there is
no point in the computation continuing. Once an error occurs, there are
only two valid courses of action. Firstly, to fail and terminate. Secondly,
to recover from the error. To continue with the computation is just
nonsensical.

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

>Yes.  Like lint.

Lint is an inappropriate tool for modern software development. Lint style
checks should be built into the language and compilers. If they are built
into the language from scratch, then you will find that many potential
warnings will be avoided. Ignoring potential errors and generating an
executable (I use the term loosely) program, is also nonsensical. This style
of software tool should be abandoned for serious software development.

>>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.

Hang on, low level systems programming requires fault tolerance and error
recovery, as much if not more that higher level programming. I think there
is general confusion here, that if you are doing low level systems programming,
then it must be done in a low level language. This is not true. Low level
systems programming can be done in high level languages, with all their
benefits.

>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.

Do people really choose C because it does the job best? I think not. C is
a lowest common denominator tool. Many C programmers will not even consider
any other language (please don't reply to this one, I know you are the
exception ;-)). If C is popular and widespread, it is because it has now
achieved a great age, and is old and tired, and is based on 25 year old
assumptions about how machines worked in those days, and the limited
power and available memory that were common. If we want the tool that does
the job best then it is overdue that C was retired in favour of young, more
spritely languages that serve the needs of today.
--
Ian Joyner  ACUS (Australian Centre for Unisys Software)    [e-mail]
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.