Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Pointers as 3-tuples (Re: JLG's flogging of horses (was Re: Relationship between C and C++))
Message-ID: <14340@lambda.UUCP>
Date: 12 Apr 90 02:49:27 GMT
References: <20145@megaron.cs.arizona.edu>
Lines: 46

From article <20145@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]                                I'm sorry Jim, but it should be
> obvious that the 3-tuple scheme does not prevent malloc() from
> working, and it really looks like you are resorting to desperate
> rhetorical ploys in an attempt to support your position.

No.  And I'll test your claim right here.  Using C, with you 3-tuple
idea, write the following routines: brk(), sbrk(), malloc(), and
free().  You won't succeed.  This is because _at_least_one_ of these
routines has to have direct explicit access to the internal representations
of your 3-tuples (something has to be responsible for setting them).
Since I maintain that the best use of explicitly visable pointers is
in the implementation of routines like those mentioned above, and your
3-tuple prevents me from doing so with C's pointers, I claim that you
have removed one of the only interesting properties of pointers.

> [...]                                                     There are
> a lot of people who think that
>   for (p = A; p < A + A_SIZE; p++) foo(*p);
> is more elegant than
>   for (i = 0; i < A_SIZE; i++) foo(A[i]);

And I guess it's just a matter of taste that I consider:

      for (i = 1; i < N-1; i++ )
         for (j = 1; j < M-1; j++ )
            A[i][j] = 0;

is better than:

      for (p = A; ???; ???)
        /* Oh what the hell.  I don't feel like working it out.
           Why don't _you_ tell me how to complete this code to
           zero the interior of a two-dimensional array.  I can't
           be bothered to work out something that the _compiler_
           should be responsible for (not at this time of night
           anyway).                                               */

What ever you come up with will either _not_ be as clear as the first
above, or it will use some macro (whose definition won't be clear).
Either way, I think my preference is _more_ than just personal taste.
(And, if it _is_ just personal taste, I think that those who share it
will outnumber those who don't - and very probably those who share it
will out-program those who don't.)

J. Giles