Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Summary: A case for pointers
Message-ID: <2710@l.cc.purdue.edu>
Date: 6 Nov 90 13:28:19 GMT
References: <2062@aber-cs.UUCP> <1990Oct26.155937.29185@maths.nott.ac.uk> <3673@stl.stc.co.uk>
Organization: Purdue University Statistics Department
Lines: 29

In article <3673@stl.stc.co.uk>, tom@nw.stl.stc.co.uk (Tom Thomson) writes:
> I cannot understand why Jim Giles wants pointers to have values which
> are addresses.  The important thing about a pointer is simply that it
> identifies (unambiguously) the thing to which it refers.  The only
> operations on a pointer are the (a) getting the thing to which it refers;
> (b) modifying the value of the thing to which it refers; (c) checking
> whether two pointers refer to the same thing. 

In producing various types of random variables efficiently, it is
desirable to use buffers and refill subroutines.  Now each buffer
and each refill routine can be changed whenever the refill is called,
and even more can be considered.

Thus the communication scheme is

	if(buffer too close to empty){
		*rprog(info_pointer);
		change info_items in registers;}

info_pointer points to an array which has the information on the buffer
needed for use, and rprog contains the location of the array to be called.
It is true that one could use associative calls, locations, etc., but how
wise is it?  We have loaders to insert pointers to things external to the
subprogram in it.  And unless we use an associative memory, somewhere
pointers will have to be used.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)