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?
Sep 11 '08
69  3115 
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
[...]
>Except that Pascal is not a dead language. It is less popular than
C, a better language for most purposes, and a much safer language.
I won't argue any of those points; they're either correct or matters
of personal opinion. But ...
>It is even intrinsically more portable than C.
What exactly does "intrinsically more portable" mean?
For example, it isn't restricted to machines that operate on binary
power word lengths. It can run on decimal machines. In general
there are far fewer restrictions, yet it is quite possible for the
programmer to impose more restrictions. I am talking about systems
that meet ISO 7185 or ISO 10206. Not Turbo. Since there are many
machines without Pascal compilers, in practice it is less portable
than C.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>It is even intrinsically more portable than C.
>What exactly does "intrinsically more portable" mean?
>For example, it isn't restricted to machines that operate on binary
power word lengths.
Presumably you don't mean that. Nothing stops C having word lengths
that are not binary powers, such as 36. But in any case:
C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>Keith Thompson wrote:
>>CBFalconer <cb********@yahoo.comwrites:
It is even intrinsically more portable than C.
What exactly does "intrinsically more portable" mean?
For example, it isn't restricted to machines that operate on binary
power word lengths.
Presumably you don't mean that. Nothing stops C having word lengths
that are not binary powers, such as 36. But in any case:
C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.
Yes, sloppy wording by me. I was actually referring to the *_MAX
values in <limits.h>. Each active bit in such a representation has
to represent a binary power for positive values, so the aggregate
can express 0 through 2**n-1. The point is that C can't be used in
a decimal or trinary machine. Admittedly there aren't many such
lying around these days.
Please don't remove attributions for material you quote. I fixed
this.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.
>Yes, sloppy wording by me. I was actually referring to the *_MAX
values in <limits.h>. Each active bit in such a representation has
to represent a binary power for positive values, so the aggregate
can express 0 through 2**n-1. The point is that C can't be used in
a decimal or trinary machine.
C can be used on those machines. The implementation just can't use
the native arithmetic unmodified in all cases.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
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.)
--
'It changed the future .. and it changed us.' /Babylon 5/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
Chris Dollin <ch**********@hp.comwrites:
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
Normally one is only interested in ones local implementation. But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".
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'm not quite sure from what angle you are coming there. A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used). If you are teaching a language then
using one is, in my small world, part and parcel of that learning
experience primarily (as I have repeated many times here) I think using
printf in code to "experiment and debug" is amateurish at the very best
for reasons well documented. Yes, yes, it does have its uses if and when
a debugger is not available.
I can see this thread being hijacked by the ISO righteous brothers so I
will kill it now.
But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>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
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.
But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".
Oh, yes. We just don't have to deal with the vagaries of the local
implementation while doing so. I don't understand your apparent
obsession with /starting/ with implementation-specific details
when
It Is Not Necessary And It Is Distracting.
>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'm not quite sure from what angle you are coming there.
I'm coming from the angle of not having to teach several things
at once.
A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used).
No doubt.
If you are teaching a language then
using one is, in my small world, part and parcel of that learning
experience primarily (as I have repeated many times here)
Yes, you have repeated this. As a teaching technique I think it
is ... significantly sub-optimal. (In something like Pop or Lisp
or Smalltalk, where the debugger is Just More Code, and one often
works by write-a-bit run-a-bit, I'd be more relaxed.)
I can see this thread being hijacked by the ISO righteous brothers
Hallelujah! Fear you my so-called singing the ISO chorus!
so I will kill it now.
Optimist.
But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.
Yes, it's perfectly straightforward.
--
'It changed the future .. and it changed us.' /Babylon 5/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>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
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. 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 one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".
Oh, yes. We just don't have to deal with the vagaries of the local
implementation while doing so. I don't understand your apparent
obsession with /starting/ with implementation-specific details
when
It Is Not Necessary And It Is Distracting.
What are you talking about? How can I NOT use implementation "specifics"
when I am demonstrating it ON an implementation. Are you seriously
suggesting that showing someone how pointers work in a debugger using
hex representations of a memory address is going to ruin them for ever?
>
>>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'm not quite sure from what angle you are coming there.
I'm coming from the angle of not having to teach several things
at once.
You are erecting meaningless straw men to support your rather strict
approach to C. Showing a pointer in a debugger is hardly killing
them. Did you never hear of learn by doing? Holy cow. The benefits of
them seeing and using these things on a real machine in a real
development tool totally obliterates any "added complexity". I hae sat
in lectures on languages with no hands on and I fall asleep in no
time. Maybe you are differnet. Most people are not. most people like the
practical approach. a 2 hour lecture on semiconductors is easily
improved on by an hour in a lab with an oscilloscope.
>
>A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used).
No doubt.
You're becoming a bit of a prig and a bore. You deny that using a
debugger to demonstrate pointers is useful? Really?
>
>If you are teaching a language then
using one is, in my small world, part and parcel of that learning
experience primarily (as I have repeated many times here)
Yes, you have repeated this. As a teaching technique I think it
is ... significantly sub-optimal. (In something like Pop or Lisp
or Smalltalk, where the debugger is Just More Code, and one often
works by write-a-bit run-a-bit, I'd be more relaxed.)
>I can see this thread being hijacked by the ISO righteous brothers
Hallelujah! Fear you my so-called singing the ISO chorus!
>so I will kill it now.
Optimist.
Indeed ...
>
>But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.
Yes, it's perfectly straightforward.
Yet you deny that using hands on approach makes it even easier? Strange.
--
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>Richard wrote:
>>Chris Dollin <ch**********@hp.comwrites:
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
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, it comes naturally.
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).
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.
>>But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".
Oh, yes. We just don't have to deal with the vagaries of the local
implementation while doing so. I don't understand your apparent
obsession with /starting/ with implementation-specific details
when
It Is Not Necessary And It Is Distracting.
What are you talking about?
Using a debugger in teaching pointers (for C; I make no claims
about their utility or otherwise in teaching assembly language).
How can I NOT use implementation "specifics"
when I am demonstrating it ON an implementation.
You can avoid mentioning the implementation-specific details of
how pointers and pointer operations are represented. I'm happy
to grant that you need an implementation-specific implementation
/of C/.
Are you seriously suggesting that showing someone how pointers
work in a debugger using hex representations of a memory address
is going to ruin them for ever?
Do you think I said anything closely resembling that? Because
I didn't. This is a strawman.
/My/ claim is that it /is not necessary/ to use a debugger to
teach about C pointers, and that they can be taught just as
effectively debugger-free [in general; there will be outliers
in both directions].
>>>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'm not quite sure from what angle you are coming there.
I'm coming from the angle of not having to teach several things
at once.
You are erecting meaningless straw men to support your rather strict
approach to C.
No, I'm adding an additional feature to the argument.
Showing a pointer in a debugger is hardly killing them.
And I never said otherwise. Whose strawman is this, then?
Did you never hear of learn by doing?
Never. The idea is completely strange to me. I have no idea
what you're talking about.
Holy cow.
I suppose it has some aspects of a religious argument.
The benefits of
them seeing and using these things on a real machine in a real
development tool totally obliterates any "added complexity". I hae sat
in lectures on languages with no hands on and I fall asleep in no
time.
Strawman. The conflation of "without a debugger" and "no hands-on"
is yours, not mine.
Maybe you are differnet. Most people are not. most people like the
practical approach.
Some do, some don't; that's a separate question of learning styles.
a 2 hour lecture on semiconductors is easily
improved on by an hour in a lab with an oscilloscope.
I suspect that depends on the topic at hand.
>>A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used).
No doubt.
You're becoming a bit of a prig and a bore. You deny that using a
debugger to demonstrate pointers is useful? Really?
I'm claiming it is /unnecessary/ and that they (and the rest of C,
as it happens) can be taught /without/ resorting to using a
debugger. In general. If one doesn't want to clutter the student's
minds with implementation-specific details.
>>But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.
Yes, it's perfectly straightforward.
Yet you deny that using hands on approach makes it even easier?
No; see above.
Strange.
From whom demons flee.
PS "Never. The idea is completely strange to me. I have no idea
what you're talking about." is NOT SERIOUS. Just in case anyone
thought otherwise.
--
'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
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
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
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, it comes naturally.
>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).
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. And I say that the tools give an advantage which
totally overshadows any overhead to learn them.
Can I ask you how many people you have taught computer languages?
Without banging my own drum I have taught C, Assembler (68000 and x86),
and others and have a reasonable track record.
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.
Possibly you prefer to sit there at a chalk board and waffle on for
hours with diagrams and arrows? If that works for you then grand. It
never did for me or the people I had been asked to get up to speed.
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.
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").
Richard wrote:
Chris Dollin <ch**********@hp.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. ja*********@verizon.net writes:
Richard wrote:
>Chris Dollin <ch**********@hp.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.
In article <gb**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>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. ga*****@shell.xmission.com (Kenny McCormack) writes:
In article <gb**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
...
>>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. ja*********@verizon.net wrote, On 22/09/08 17:18:
Richard wrote:
>Chris Dollin <ch**********@hp.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.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
In article <gb**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
>ga*****@shell.xmission.com (Kenny McCormack) writes:
>In article <gb**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
...
>>>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.
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
On 22 Sep, 14:11, Chris Dollin <chris.dol...@hp.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
Chris Dollin <ch**********@hp.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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Xah Lee |
last post by:
in March, i posted a essay “What is Expressiveness in a Computer
Language”, archived at:
http://xahlee.org/perl-python/what_is_expresiveness.html
I was informed then that there is a academic...
|
by: slartybartfast |
last post by:
I'm new(ish) to css, comfortable using tables, but trying real hard to move away.
Please see http://84.9.125.31/developer/css_test/test5.html
NB This issue is with IE & Opera - I've tried IE...
|
by: Tubular Technician |
last post by:
Hello, World!
Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,
* size_t is the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development projectplanning, coding, testing,...
| |
