>> Sean: Professor Brailsford! We are doing our series
on the most important things you can do in Computer 
Science or something that, y'know, you couldn't 
do without. So, what have you got for us today?
>> DFB: very well.  I think my most important
thing - and we're going to sort of share this
discussion Steve Bagley and I - because I
think we are very much agreed that one of
the most powerful concepts, constructs, in
computer science is just the idea of a pointer.
One of the uses of pointers that's
easiest to understand is in linked lists.
We're going to use Lego to illustrate
linked lists. I know that some of you are
demon programmers and could take it if I
just ran through a program with you, but
I think a lot of you, who are beginners,
perhaps might appreciate having a more
pictorial introduction to linked lists.
So, at great mental expense, Sean and I have
developed a LEGO model of the linked lists
we want to talk about and we'll
gradually introduce the elements of this
as we go along. Bbut the first thing to
say is that pointers are pieces of - I
don't know what they are in LEGO - 
firemen's hoses, or connectors, or
whatever they're called. That is a
pointer of some sort. In order to bring
this home and make it more concrete you've
got to say: "Well, what are we linking
together?" And, once again, I mean this has
been referred to in Brian Kernighan's
thing about Associative Arrays - he
pointed off to singly linked lists and
each of the elements within these singly
linked lists contained a string. What I'm
going to start with is, basically, a  piece
of Lego underneath a small section of C
coding! I'm going to go through this very
carefully and - those of you who aren't demon
programmers - don't get panicked about it.
I'll try and go very slowly and explain to
you what's happening. This is what I am
going to call a THING. Whenever you look
later on and say: "What is that grey
baseplate doing - what does it signify?"
`Grey base plate' means it's a THING. What
are the components of a THING?
Well, a red box sitting on top of the THING 
holds a [pointer to] a string of characters, and
again we're going to follow up with the
idea of things you might buy for a barbecue:
burgers,chips wine - stuff like
that. But because it's a singly-linked
list the other box sitting within the
structure is going to point off to the
next THING along in this singly-linked
list. If that's a THING then, the only bit
of programming I'm going to do today,
honest - this is it - is to just show you
how this would be declared in the C
language. I'm using a `typedef'
declaration because I just want to be
able to use the shorthand of THING. A bit
like `int'. Instead of saying `int sean;'
[where] `sean' is an integer and can
have contents. I just want to say: THING sean;
But in order to be able to 
make that abbreviation, and to cut the
clutter a lot, I have to give what's
called a `typedef'. This is a definition of what
a structure of type THING really is. And
all it's saying, in here, if you look at it
is `char *item'. Now, what that is
saying - this is again, those of you
familiar with C will know - it's a
standard C way of saying: "It's a pointer
to a char apparently". But actually they
cheat a bit because it's not just a
pointer to a single character, it can be
a pointer to a great long string of characters 
>> Sean: Does `char' mean character?
>> DFB: `char'  is 
short for character, yes. Some people call it 
`car'; some people call it `char' but it's
basically ... if you point at the first
character in a string then you're pointing
at the whole thing because you just step along
it sequentially. And here for the blue
box in my model I've got to say: "Well how
do I point at the next THING along in my
list?" Well, I hope you can see there's a
sort of bit of recursion in the
definition here. But the compiler knows
you can do things like this and doesn't
panic. You've got a `struct _thing'
inside here, referring back to this
`struct _thing'. What it's saying
is that this THING I'm calling `next'
within the structure, is a pointer to the 
next THING.
So what are these things known as then
- this  `item' and `next'? They're called
`members' in C;  `next' is also a member. 
In other languages you'll find these
"internal identifiers" - if you like -within a
structure, are called different things. I mean
in Algol68, where I started, they were
called `fields' of the structure. Those are
just so that you can pick out the
components of your structure and
remember, the overall package of a
pointer to the next one; a red box which
means "I can contain a string of
arbitrary size", mount the whole thing up
on a piece of grey LEGO and the whole
thing is a THING. We've got the basic
building block then of what we need to
start building together, linked lists. Now
some of you are going to say: "Hey, come on,
you're glossing over actuality".  Because
obviously this `next' member field is
going to have a pointer in it to the
next one of these THINGs but you haven't
said that inside the [item] string box you
can't just put a string inside an
address box - it might not be big enough
to hold "supercalifragilisticexpialidocious". 
Yeah!
Quite right! Those of you `in the know' 
will know that,
within this box that contains a string
you will have -  well it says so here - you
must create yourself enough space to
hold the string and point at it. We draw
a veil over that for the moment. Just
imagine that it doesn't matter what the
string is -- "burgers", "zucchini", whatever - 
we can create enough space in the red box
to hold that string - make it identifiable.
I'm going to put out the code for this
program, and any subsequent ones, in the
usual way - available to you in C. I'll
try and get my indentation so it doesn't
make those are you care passionately about
these things .... Mind you, there'll
be Iindentation Wars. Some people will
love the way I've done it; other people
will hate it. But we'll live with that.
But yes, the idea of this, going through
this model, purely with LEGO is that if
you then get hold of the program, look
back at the video, try and follow all the
things I'm doing and say: "Well how does the
program do that?"  And see if you can
understand, as we go along. I wish in many
ways I'd thought about trying to do
this when I was teaching link-lists to
third-year undergrads. I think it might have
helped some of them who were very
pictorial in the way they wanted to look 
at things.
Once we've declared at the top of our C
program that this whole thing is called
a THING, I can then say, later on in the
program if I wanted to: `THING sean;' just
like saying `int sean;'  But this is a
THING.  OK we haven't filled in your
likes and dislikes Sean. What's your
favorite stuff at barbecue?
>> Sean:  sausages.
>> DFB: Sausages!  So that, of course, is the
barbecue item that Sean likes best. Now
if I've named my THING which I have, and
given this an identifier name, I can say
things like: `sean.item = "sausages";'
And that works fine because if
you give an explicit string of
characters in C it will, at compile time,
find the space to hold that for you. So
that should work OK. And there's also
no prizes for guessing that, perhaps for
cleanliness, I ought to fill in what the
`next' field of `sean' is. And there is a
standard way of saying [that] it's the zero
pointer. It points nowhere!. It's called
NIL [or] it's called NULL. It's not been filled in
yet but you've got to fill it in with
something, so you fill it in with NULL.
A stage beyond that is to say `THING *p;'
Now if you're happy that `char *item''
within the structure, means "pointer to a
string of characters" then it follows
that the type of p is `pointer to THING'.
So I haven't filled anything in here yet
This contains nothing, this box, but I
could overwrite it with a pointer to
`sean' if I wanted to do that.
OK, so we will be developing, quite a
lot, the idea that we don't necessarily
deal always directly with THINGs. We
stand back one level and we
use pointers to THINGs. It makes good
sense, because within the list of
structures we're developing, as you know,
the `next' field is of type `pointer to a THING'.
I guess at this stage, perhaps, to
make this a bit more concrete, we could
turn our attention now over to the LEGO
and in that infuriating way that they do
on home-help or do-it-yourself programs on
TV, I'm going to say "Here's one I
prepared already :-) " The idea in this
particular linked-list of barbecue items
is that there are strings inside each of
these red boxes, as we've discussed, and
these strings of characters correspond
to things you might want on the barbecue.
But we are so neat and tidy we want to
keep these in alphabetical order, so look
at this: the string content in that red
box says "beer" "chips" "pizza" "slaw" "wine". So
don't forget these are the contents of
the boxes. The member name of each box is
always the same. It's always the `item' part of
the particular thing you're on at the
moment. And the pointer here is the `next'
part of that block. But it's all
beautifully set up, look, every one of
your `next' boxes really does point to the
start address of the next THING. All the
way down they're all in alphabetical
order. But the one aspect we didn't
mention, which is vital, is that you must
set up a pointer to the head of the
linked list. If you don't have that you
can't reference anything. What we're
saying here is, it's not part of linked
list processing in general to give each
of these THING structures its own [identifier] name.
I mean I could call them Sean,
Dave, Steve, Mike and Robert, or something
like that. But no, life's too short, I'd run
out of names. No, keep them all in order
but just retain one pointer that tells
you what is the lead item in there.
So, this start pointer. Look at the colour
coding. It's blue. So it's a `THING *', or
as we used to say in Algol68, it's a `reference
to a THING. You jump onto the pointer at
the start address of the THING. 
And inside that you can say give me the 
`item', give me the
`next' and so on. But the big question now
is - it's all beautiful - but suppose
actually I was told to get some burgers
but they didn't have them available at
the first supermarket I went in.  So I had
to go somewhere else and get some
burgers and unfortunately Brian or Sean
has made this list up already. So
determinaedly keeping it alphabetic, if I
prepare over here a new THING with
"burgers" ready to be put in, how do I
traverse down this list, find out where
it belongs, alphabetically? And get it to
work so that I can fiddle with the
pointers and link it in?  [A] quick check will
show you that "burgers" belongs after "beer"
but before "chips". Therefore what you need
is a probe to look inside each of these
structures and to tell you what is
inside there in terms ofn the `item' field.
Now I can't use `start' as the probe.
If I move that away from the head of the
list I'm sunk. I'll never find that
wretched list ever again. You mustn't use
start as your roving pointer! But what I
can do - just like the thing called `p' I
developed - let's call this `p' - for the 
[roving] pointer. If I first of all copy 
over the contents
of `start' into `p', which is also of type
`reference to THING' then I hope you'll all
agree that what will happen is I've now got
this THING * called `p' which is pointing at
exactly the same structure, at the head
of the list, as `start' is. So hope I've
got enough finger-power here to do it. There you
go! You start with `p', up here, and you say:
"What's the `item' within that THING I'm
pointing at now? It says "beer". So, "burgers"
goes after "beer" then move that from
there to there and use it as a probe to
ask what is the `item' entry in that one? "chips" !
Aagh! it needs to be earlier than "chips" ! So, you can see
here you've got a bit of a problem with
a singly-linked list; if you move the
pointer too far you end up with "chips".
But you say:
"Ah! but I want to insert it before "chips" 
but after "beer". I want to be back at this
address". So what I'm saying is it's
perfectly possible to do it. You've got to
be very careful. You've got to come in.
you've got to say :"That one's beer". 
Then you've very carefully got to take a look at
this `next' field and say: "Should I follow
that pointer and see what's in the `next'
blue box?" You can do that, it's fine, but be
so careful that it doesn't contain NIL / NULL.
It could be a very short list. It
could be that there's only one item in it.
And right down at the bottom here - this
thing that looks like something from
Angry Birds - denotes NULL. and if you 
start trying to follow the NULL pointer
your program will go "bang" and will say:
Segmentation Violation. Well, that's fine,
but it needs some careful programming.
But it can be done and I will give you a
solution that does it,just that way. Next
thing you've got to sort of say to
yourself though is: "When I've found where I
want to be how do I bind in the new
THING?" Well, the actual construction process, 
if you like, of putting in the new THING,
once you've discovered that "burgers"
needs to go in here somewhere,
is to do this: you've got to - we'll use an
extra long pointer here which points to
our newly created thing, and we are
then going to take the old pointer that
was in there and put it as going from
here to here. So, look, we've done it! We go
"beer" follow the pointer to a THING
that's got "burgers" - let's move that out
of the way - follow the pointer to a THING
that's called "chips". So, we've inserted
"burgers". So it's just pointer
manipulation once you've discovered
where you are. What you need in this - and
it's really frustrating -
you need to keep your finger in two
places - or you need two fingers - let's put
it that way. You want to remember the one
you just looked at; you want to take a
look at the next one and say: "Yes, it's in-
between those two. We've done it we've
patched in our new THING for "burgers". So,
let me just sort of summarize some of
the problems. Obsessively keep
checking for NULL- obsessively. If you
dereference that- BANG! - you're dead.
And that brings into
question certain special cases. What
happens if I want to insert something at
the end of a list where NULL is parked
there already? I've got to be very
careful there. Suppose I wanted put
"zucchini",  or something, in at the bottom
below "wine"? That might be a problem. Even
worse problem, potentially, might be if I
wanted to put something in at the head
of the list - ahead of what's there already?
I mean, under those circumstances what
you'd be saying is: "Something beginning
with `a' Sean? "avocado" to make guacamole
with?" If we want to put "avocado" here then
what you will have to do is to create a
new THING there and move that to point at
"avocado" and then make "avocado"s link
point at that one.  So this is "avocado"
that would be start of your list now and you'd
have an internal one [a pointer] to complete it,
going from here to here. Now here is a
big problem because you'd better get
this right, because notice you have
actually altered `start'. What I was saying,
all along, was be careful with `start'.
It's your pointer to the head of the
list. But if you get something like
"avocado" that has to be the new head of
the list then you must make sure that
the `start' pointer gets updated. Another
special case that's got to be put in
your code. So, be obsessive about checking
for NULL. Can you cope with things
inserted at the head, the very start of
the list? Can you cope with
putting "zucchini" at the end? Is it all
nice and clean? You'll see, in the
solution I gave you that there has to be
a lot of special-case checking to get
all of this right. But, on the other hand,
you can make it work.
But you will in general need some sort
of roving pointer, or pointers, moving
down the list to check what you're
pointing at and what the next one is. Now
if you look at that code and say: "Oh! it's
yukky - it's horrible - can't you do any
better than that?"
It's not easy! However, there is a top-
secret trick, which actually makes it so
much easier to do that. It'll have to be a
separate video. Sorry to leave you with
cliffhangers folks but it's becoming
almost a "Computerphile" tradition now,
isn't it?!  So, what would make life a lot easier
is instead of just having THING *, I mean we
can't do away with it -- we've got it.
But you know it's a blue thing. It points
to a structure of type THING  - is if we
introduce the concept of a pointer to a
pointer to a THING and this is what a
green box signifies. I've got some extra
long linkage here. I'm going to put that
on there. So I hope you're all happy
because this is really doing type theory
- elementary type theory - in a way that
would make my functional colleagues
blench, but I'll try not to say anything
too obviously untrue. You'll have to
agree with me that if the contents of a
blue box is a `reference to a THING' then
if you step one beyond it you're
referring to a ref THING, or the THING *,
or whatever. So the contents of the
green box would be a ref ref thing, or in
C notation a THING **. Assemblerr
programmers among you may say: "Oh! come 
on this is just type-safe nonsense.
They're all pointers - just mess about
with them, do what you want with them, and
don't make any mistakes!"
Now what I like about C is it's a nice
half-way house. It gives you a bit of
type-safe capability. It does distinguish
between a pointer to a THING and a
pointer to a pointer to a THING and
makes you very carefully get the level
of your pointing correct. But what can
be revealed in the future is that that
simple trick, of this [green] thing containing a
pointer to a pointer, can solve a huge number of problems.
