What's the position of pointers

[Yee.Chuang]

When I began to learn C, My teacher told me that pointer is the most
difficult part of C, it makes me afraid of it. After finishing C
program class, I found that all the code I wrote in C contains little
pointers, obviously I avoid using them.
A few days ago when I was reading a book about programming, I was told
that pointers are the very essence of C language, if I couldn't use it
well, I'm a bad programmer, it's a big shock.
So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?

[jameskuyper]

Richard wrote:
....

Normally one is only interested in ones local implementation.

That has not been my experience. I've seldom had any need to know
anything about pointers that was specific to a particular
implementation while programming in C. Interfacing between C and
assembler, for instance, is a different matter - for that kind of work
you have to know the details. However, if you can use C exclusively in
your program, it generally insulates you from needing to know such
details.

Two decades ago I did have to learn about near and far pointers and
how they were implemented, because I was programming for DOS/Windows,
but I generally tried to write my code, even for those platforms, so
it avoided any explicit use of that extension. I haven't had to worry
about such issues for more than 15 years now.

... But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence". ...

Yes, but it's easier to explain those things in a platform independent
fashion, without going into the complexities of platform-specific
issues. You can add in the platform-dependent aspects as and when
needed (in an introductory course, "when" is probably "never").

[jameskuyper]

Richard wrote:

Chris Dollin <ch**********@h p.comwrites:

Richard wrote:

....

Normally one is only interested in ones local implementation.

No, /mornally/ one isn't interested in one's local implementation;
one is interested in teaching or understanding the language & code
one is writing.

You are being purposely difficult. ...

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

... In the context of TEACHING. i.e it is
on THAT implementation that one is using tools to demonstrate the
theory. I have done a lot of it. And successfully (according to 3rd
party adjudication).

But there's no need to emphasize any of the implementation-specific
details, unless it's a really unusual machine. Your students stand a
very good chance of ending up working on machines quite different from
the one you're teaching on. Platform-specific features should be a low
priority; there's way too many platform independent things that they
should learn first, because they are more important than platform-
specific features.

[Ben Bacarisse]

ja*********@ver izon.net writes:

Richard wrote:

>Chris Dollin <ch**********@h p.comwrites:

Richard wrote:

...

>Normally one is only interested in ones local implementation.

No, /mornally/ one isn't interested in one's local implementation;
one is interested in teaching or understanding the language & code
one is writing.

You are being purposely difficult. ...

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

I marked this message because I felt I need to explain why I disagreed
with Richard. I am glad, now, that I waited a bit because I could not
have said it better.

--
Ben.

[Kenny McCormack]

In article <gb**********@r egistered.motza rella.org>,
Richard <rg****@gmail.c omwrote:
....

>I understand fully.

But to recognise that these tools are good for others is paramount. What
I dont like from some of the clowns here is that these tools are not
beneficial to the majority or that they have no place. They are and they
do.

But, for the reasons I've just described, you'll never get them (or me!)
to admit it.

You'd just be wasting your breath.

[Richard]

ga*****@shell.x mission.com (Kenny McCormack) writes:

In article <gb**********@r egistered.motza rella.org>,
Richard <rg****@gmail.c omwrote:
...

>>I understand fully.

But to recognise that these tools are good for others is paramount. What
I dont like from some of the clowns here is that these tools are not
beneficial to the majority or that they have no place. They are and they
do.

But, for the reasons I've just described, you'll never get them (or me!)
to admit it.

You'd just be wasting your breath.

Aha. Now I fully understand you. You are not defending your
reasonings. They are just your (hard earned) preferences and reasoning
be damned. That I can except.

[Flash Gordon]

ja*********@ver izon.net wrote, On 22/09/08 17:18:

Richard wrote:

>Chris Dollin <ch**********@h p.comwrites:

>>Richard wrote:

...

>>>Normally one is only interested in ones local implementation.
No, /mornally/ one isn't interested in one's local implementation;
one is interested in teaching or understanding the language & code
one is writing.

You are being purposely difficult. ...

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

<snip>

To explain pointers I would (and have) started off from the point of not
needing a programming language let alone the details of one specific
programming language. From this perspective I have managed to not only
explain pointer to someone who does not know how to program, but also
explain buffer overflows and why they don't always cause a visible
effect to someone who does not know how to program. IMHO the concept of
pointers is far too simple to need to go in to real detail unless you
are programming in assembler or have enough experience to start dealing
with fixing really obscure bugs.
--
Flash Gordon
If spamming me sent it to sm**@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Kenny McCormack]

In article <gb**********@r egistered.motza rella.org>,
Richard <rg****@gmail.c omwrote:

>ga*****@shell. xmission.com (Kenny McCormack) writes:

>In article <gb**********@r egistered.motza rella.org>,
Richard <rg****@gmail.c omwrote:
...

>>>I understand fully.

But to recognise that these tools are good for others is paramount. What
I dont like from some of the clowns here is that these tools are not
beneficial to the majority or that they have no place. They are and they
do.

There is another side to this argument, but I won't go into it at the
moment.

>But, for the reasons I've just described, you'll never get them (or me!)
to admit it.

You'd just be wasting your breath.

Aha. Now I fully understand you. You are not defending your
reasonings. They are just your (hard earned) preferences and reasoning
be damned. That I can except^Waccept.

Yes. The difference between me and the CLC regs is that I am honest
about it.

[Chris Dollin]

Richard wrote:

>I have never said that you haven't. What I'm saying is that I
don't think that's the best way to teach pointers, because it
introduces unnecessary details & tools.

I know you have.

Then stop arguing with me as though I'd said something different.

And I say that the tools give an advantage which
totally overshadows any overhead to learn them.

That is at least a respectable argument. (We differ about the
value of the advantage, but you already knew that.)

Can I ask you how many people you have taught computer languages?

Not many; it's been too long since I had to.

I *know* that in my style of teaching that pointers and similar are no
more difficult that the concept of a while loop for example when taught
using the tools to do the job.

Good. FRichard, I really don't have a problem with your ability
to teach pointers or C or whatever, just with your claims that
it's /necessary/ to introduce these implementation-dependencies
to teach them effectively. May claim is, and has been, that it's
not /necessary/, and I also believe that it's extra load for
students to handle those implementation dependencies and learning
how to use the debugger.

You have said that you use the debugger routinely, so it's not
surprising to me that you value it and teach how to use it. I
don't value it as much as you, and I wouldn't /dream/ of using
it as a teaching tool in the early stages of teaching C. I
think such concentration on low-level details makes it harder
to teach the "big picture"; because C is so strong in dealing
with the low level, it's /really important/ to show how to
handle the less-detailed stuff.

What you see as a strength, I see as an issue. I don't think
we're likely to change /those/ views. I'm not arguing to
convince you (although of course that would be nice); I'm
arguing to try and pick around the subject and expose it so
that people can get a sense of what the options and considerations
are and take away whatever they find valuable.

Possibly you prefer to sit there at a chalk board and waffle on for
hours with diagrams and arrows?

You do an awful job of guessing what it is I'd do if I were
to seriously try and teach someone C nowadays. Sorry.

But I know where this is heading. its the old "debuggers are evil"
mentality again and "hard to use". Well they are not and they are
not. they are trivial to use and add much to the development/learning
process.

I know you think so, and you know I think otherwise, and we've both
vented on thsi topic before.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Nick Keighley]

On 22 Sep, 14:11, Chris Dollin <chris.dol...@h p.comwrote:

Richard wrote:

I can see this thread being hijacked by the ISO righteous brothers

Hallelujah! Fear you my so-called singing the ISO chorus!

myself, I go back to the older, deeper ANSI Chorus!!

Fnar Fnar Fnar!

--
Nick Keighley

[Richard Bos]

Chris Dollin <ch**********@h p.comwrote:

Richard wrote:

You do not recommend an entirely different language to someone to learn
something as core and basic is pointer usage. The basics ARE simple and
any teacher worth his salt can get it across with a debugger and an OHP
in 2 or 3 minutes.

Or without a debugger. One might want a debugger to show how your
local implementation does things; one doesn't need one to explain
what they /mean/. (This is especially useful when it means one isn't
having to explain a debugger at the same time as a programming
language.)

I would go so far as to say that someone who needs to use a debugger to
either teach, or understand, the fundamentals of pointer usage, neither
does nor will understand pointers. A pointer, despite frequent
protestations to the contrary, is neither a number nor a one-up-one-down
"address". It's an address in the full, complex meaning of that term: it
can contain one or several parts, several of them may or may not follow
up on one another despite what the number(s) in one (or more) of the
parts say, and looking at how they're written down does not make you
understand how they work.
This is as true for pointers as for street addresses. Anyone expecting
to be near Great Ormond Street Hospital because he's on Great Guildford
Street (which backs on (non-"Great") Guildford Street) in London is
quite mistaken; and anyone who expects 03:acc8:04bf to be "close",
whatever that means, to 02:acc8:04bf, or even to be the "equivalent ",
whatever _that_ may be, of 03:acc8:04bf in Security Section 02, is
equally as mistaken.

(_Implementing_ pointers is another matter, of course. That's inherently
platform-specific - highly so, in fact - and in that case, a debugger is
a very useful tool indeed.)

Richard