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  3221 
Keith Thompson wrote:
CBFalconer <cb********@yah oo.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 "intrinsica lly 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********@mai neline.netwrote :
>>It is even intrinsically more portable than C.
>What exactly does "intrinsica lly 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********@mai neline.netwrote :
>Keith Thompson wrote:
>>CBFalconer <cb********@yah oo.comwrites:
It is even intrinsically more portable than C.
What exactly does "intrinsica lly 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********@mai neline.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**********@h p.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**********@h p.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**********@h p.comwrites:
Richard wrote:
>Chris Dollin <ch**********@h p.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**********@h p.comwrites:
>Richard wrote:
>>Chris Dollin <ch**********@h p.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
implementati on 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**********@h p.comwrites:
Richard wrote:
>Chris Dollin <ch**********@h p.comwrites:
>>Richard wrote:
Chris Dollin <ch**********@h p.comwrites:
Richard wrote:
>
>You do not recommend an entirely different language to someone to learn
>somethin g 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. 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 paper written on this
subject.
On the Expressive Power of Programming Languages, by Matthias
Felleisen, 1990.
http://www.ccs.neu.edu/home/cobbe/pl-seminar-jr/notes/2003-sep-26/expressive-slides.pdf
|
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 6&7 and both have the same result. It works fine in FF. Thanks to Petr Stanicek for the original example.
As you can see the table is 800px wide in the middle column and it's vertical position is affected by the amount of text in the left or right...
|
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 right thing to use for every var that holds the
number of or size in bytes of things.
* size_t should only be used when dealing with library functions.
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
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, and deploymentwithout human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupr who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
