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?
69  3128 
On 2008-09-11 13:02:27 +0100, "Yee.Chuang" <mc*******@gmail.comsaid:
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?
Essential.
The standard library makes heavy use of them, as do most APIs. Also
things like passing arrays to functions decay into a pointer and so on
and so forth. Passing structs between functions, dynamic memory
allocation. The list is endless.
If you don't use pointers in C why don't you use a language like Python
instead?
--
"I disapprove of what you say, but I'll defend to the death your right
to say it." - Voltaire
Yee.Chuang wrote:
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?
Half of learning C, is learning to write functions.
Half of learning C, is learning to use pointers.
The other Half of learning C, is learning everything else about C.
Does that add up right? ;)
Most of the standard library functions,
take pointers as arguments,
so there is some importance to learning pointers well.
I mostly use pointers at every given opportunity.
You are most likely using subexpressions
which are being converted to pointer types,
without you being aware of it,
whenever you write code that you think avoids the use of pointers.
--
pete
Yee.Chuang said:
When I began to learn C, My teacher told me that pointer is the most
difficult part of C,
He probably told you that not because they're hard to learn (they aren't!),
but because they're hard to teach!
it makes me afraid of it.
Yes, you're not alone. But it's worth overcoming that fear, because
pointers are the very essence of the C language. And once you "get" them,
your eyes will light up, and the word "POWER!" will pop into your head,
and there'll be no stopping you.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Yee.Chuang wrote:
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.
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several years, and
before that BASIC, which didn't even have the concept at all.
What's funny is that, when I finally forced myself to learn, pointers
turned out to be a lot easier to deal with than I expected. There just
aren't many good books that teach it right, nor teachers who really
understand it well enough to explain it well to students.
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.
I have to agree with that.
So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
You really can't unlock the power that C offers without understanding
and using pointers. If you don't, you're really just writing Pascal
that looks like C.
S
Stephen Sprunk wrote:
Yee.Chuang wrote:
>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.
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
Then you weren't using Pascal thoroughly. The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. This allows Pascal to check
for most common errors, unlike C.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Yee.Chuang wrote:
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?
In general you need pointers to build dynamic data structures like
linked lists. In C you also need pointers to simulate call by reference.
August
On 11 Sep, 22:28, CBFalconer <cbfalco...@yahoo.comwrote:
Stephen Sprunk wrote:
Yee.Chuang wrote:
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.
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
Then you weren't using Pascal thoroughly. *The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. *This allows Pascal to check
for most common errors, unlike C.
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
--
Nick Keighley
Unicode is an international standard character set that can be used
to write documents in almost any language you're likely to speak,
learn or encounter in your lifetime, barring alien abduction.
(XML in a Nutshell)
On Sep 12, 5:03*pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 11 Sep, 22:28, CBFalconer <cbfalco...@yahoo.comwrote:
Stephen Sprunk wrote:
Yee.Chuang wrote:
>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.
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
Then you weren't using Pascal thoroughly. *The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. *This allows Pascal to check
for most common errors, unlike C.
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
--
Nick Keighley
Unicode is an international standard character set that can be used
to write documents in almost any language you're likely to speak,
learn or encounter in your lifetime, barring alien abduction.
* * * * * * *(XML in a Nutshell)
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
On Sep 12, 12:20 pm, "Yee.Chuang" <mcdrag...@gmail.comwrote:
On Sep 12, 5:03 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 11 Sep, 22:28, CBFalconer <cbfalco...@yahoo.comwrote:
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
Pointers are not a unique concept in C.
A pointer points to something. You can access that something via the
pointer.
That's all there is to it, as a generic concept.
Now, if you want to learn C pointers, first you'd have to understand
C's type system.
Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])
That's half the work. The other half is to read the semantics of
pointers.
HTH. vi******@gmail.com writes:
On Sep 12, 12:20 pm, "Yee.Chuang" <mcdrag...@gmail.comwrote:
>On Sep 12, 5:03 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 11 Sep, 22:28, CBFalconer <cbfalco...@yahoo.comwrote:
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
Pointers are not a unique concept in C.
A pointer points to something. You can access that something via the
pointer.
That's all there is to it, as a generic concept.
Now, if you want to learn C pointers, first you'd have to understand
C's type system.
Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])
"p is char[4][2]"? I know pointers and I dont understand your example or
what you are trying to say.
<vi******@gmail.comwrote in message
news:5f**********************************@2g2000hs n.googlegroups.com...
On Sep 12, 12:20 pm, "Yee.Chuang" <mcdrag...@gmail.comwrote:
>Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
Pointers are not a unique concept in C.
A pointer points to something. You can access that something via the
pointer.
That's all there is to it, as a generic concept.
Not quite. Those other languages use pointers behind the scenes, they
already have the 'something'.
C needs pointers just to implement those 'something's in the first place, or
to push them around. They're not an optional extra, not for dealing with
dynamic or flexible data.
Now, if you want to learn C pointers, first you'd have to understand
C's type system.
Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])
I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.
--
Bartc
On Thu, 11 Sep 2008 12:41:13 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
>Yee.Chuang said:
>When I began to learn C, My teacher told me that pointer is the most
difficult part of C,
He probably told you that not because they're hard to learn (they aren't!),
but because they're hard to teach!
Maybe pointers were mysterious to him. Or he felt them too dangerous
for a beginner, which we hear often. But we learn best by making
mistakes and then correcting them. Taking risks is the best part of
living.
>it makes me afraid of it.
Overcoming your fears is glorious!
>
Yes, you're not alone. But it's worth overcoming that fear, because
pointers are the very essence of the C language. And once you "get" them,
your eyes will light up, and the word "POWER!" will pop into your head,
and there'll be no stopping you.
"Yee.Chuang" wrote:
Nick Keighley <nick_keighley_nos...@hotmail.comwrote:
>CBFalconer <cbfalco...@yahoo.comwrote:
>>Stephen Sprunk wrote:
Yee.Chuang wrote:
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.
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
Then you weren't using Pascal thoroughly. The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. This allows Pascal to check
for most common errors, unlike C.
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. Then returning to C would
mean abandoning the safety and adding new capabilities.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
"Yee.Chuang" wrote:
>Nick Keighley <nick_keighley_nos...@hotmail.comwrote:
>>CBFalconer <cbfalco...@yahoo.comwrote:
Stephen Sprunk wrote:
Yee.Chuang wrote:
>
>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.
>
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
Then you weren't using Pascal thoroughly. The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. This allows Pascal to check
for most common errors, unlike C.
yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations not
met by C.
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
On Sep 12, 11:45*pm, Richard<rgr...@gmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrites:
"Yee.Chuang" wrote:
Nick Keighley <nick_keighley_nos...@hotmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrote:
Stephen Sprunk wrote:
Yee.Chuang wrote:
>>>>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.
>>>That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
>>Then you weren't using Pascal thoroughly. *The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. *This allows Pascal to check
for most common errors, unlike C.
>yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
>On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. *Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations not
met by C.
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
Hey, Richard, it's not so serious about that so called "atrocious
advice". I came here for your advise. Thanks for all of your
instructions, now I know more about points than I used to do, that's
great and fun.
There was no malice in their discussions.
"Yee.Chuang" <mc*******@gmail.comwrites:
On Sep 12, 11:45*pm, Richard<rgr...@gmail.comwrote:
>CBFalconer <cbfalco...@yahoo.comwrites:
"Yee.Chuang" wrote:
Nick Keighley <nick_keighley_nos...@hotmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrote:
Stephen Sprunk wrote:
Yee.Chuang wrote:
>>>>>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.
>>>>That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several
years, and before that BASIC, which didn't even have the concept
at all.
>>>Then you weren't using Pascal thoroughly. *The prime uses of
pointers are very similar between Pascal and C, but Pascal doesn't
allow the loose generic conversion of VAR parameters to pointers,
and similar things for arrays, etc. *This allows Pascal to check
for most common errors, unlike C.
>>yes I moved from pascal to C and didn't find pointers a problem.
They seemed very like pascal pointers. Though I thought the sysntax
was *very* strange!
>>On the other hand I'd programmed in Coral, Assmebler and had
brief exposure to BCPL. So pointers seemed quite normal!
>Something I forgot to tell: C is the first language I've learned,
after that I understand the basic skills of programming. Most of the
time I just use software like SAS, Matlab and R to solve problems.
Yes, I don't write any software, I just use them.
If learning pointers can help me with programing thoughts or improve
my program skills, I'm glad to do so.
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. *Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations not
met by C.
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
Hey, Richard, it's not so serious about that so called "atrocious
advice". I came here for your advise. Thanks for all of your
instructions, now I know more about points than I used to do, that's
great and fun.
There was no malice in their discussions.
I realise there was no malice. But it was a silly idea to tell someone
to learn an entire different language to teach what is, after all, a
relatively simple concept when approached in the correct
manner. Especially an effectively dead language such as Pascal which
Falconer seems to love.
Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>
>If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations
not met by C.
Except that it duplicates my experience of long long ago, and I
have no problems with C pointers.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
Richard wrote:
>CBFalconer <cb********@yahoo.comwrites:
... snip ...
>>
>>If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations
not met by C.
Except that it duplicates my experience of long long ago, and I
have no problems with C pointers.
Of long long ago.
I have experience of new C programmers and have never, ever had a
problem explaining them pointers and de referencing pointers. I tend to
use a debugger a block of memory. Easy.
They do not need to learn a dead language like Pascal to understand
pointers.
On Sep 11, 5:02 am, "Yee.Chuang" <mcdrag...@gmail.comwrote:
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?
I personally had more issues with the math end of C than pointers
themselves. Yes, I had real issues with the concepts of logical
conjunction, disjunction, implication, and NAND. De Morgans law also
bit me. With that, I'm just going back to being a silent bystander on
this forum.
So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
Try to solve the following problem based on your current knowledge.
If you are able to solve it without using the pointers, you don't need
to learn.
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
int a;
a = 5;
X(??????); //line # 5
printf("\n Value of a is %d",a);
retrun 0;
}
---------------Desired OUTPUT -----------
Value of a is 20
Problem Statement
-----------------------
In the above code, at all the places where you see "?????" you have to
write some C Code.
you have to write the code such that without modifying the variable
"a" in main, value of "a" becomes 20. That is the output of program
when run is as shown in desired output.
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
Richard<rg****@gmail.comwrites:
[...]
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
Treating pointers simply as machine addresses can easily lead to the
assumption of a single linear address space. That's a common
implementation, but it's not required. For example, as far as C is
concerned, pointers to two independently declared objects have no
defined relationship to each other (other than inequality), and even
computing ``&x < &y'' invokes undefined behavior.
A C pointer is a more abstract concept than you're implying, defined
in such a way that a machine address pointing somewhere in monolithic
linear memory is one way, but not the only way, to implement them.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" sh******@gmail.com said:
>
>So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
Try to solve the following problem based on your current knowledge.
If you are able to solve it without using the pointers, you don't need
to learn.
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
int a;
a = 5;
X(??????); //line # 5
printf("\n Value of a is %d",a);
retrun 0;
}
---------------Desired OUTPUT -----------
Value of a is 20
Problem Statement
-----------------------
In the above code, at all the places where you see "?????" you have to
write some C Code.
you have to write the code such that without modifying the variable
"a" in main, value of "a" becomes 20. That is the output of program
when run is as shown in desired output.
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
void X(int ignore){
int puts(const char *);
void exit(int);
puts("Value of a is 20");
exit(0);
}
int main(int cnt, char *aa[]){
int a;
a = 5;
X(a); //line # 5
printf("\n Value of a is %d",a);
retrun 0;
}
(You might want to try again.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999 sh******@gmail.com writes:
>So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
Try to solve the following problem based on your current knowledge.
If you are able to solve it without using the pointers, you don't need
to learn.
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
main's two parameters can legally be given any name you like, but
they're traditionally called argc and argv. Calling them anything
else is obfuscation. And since you don't use them, you can omit them,
declaring main as "int main(void)".
int a;
a = 5;
Ok, but why not use an initializer? "int a = 5;".
X(??????); //line # 5
Um that's not line 5, unless the definition of X is in a separate
source file.
printf("\n Value of a is %d",a);
You have a call to printf. Where's the required #include <stdio.h>?
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from. This prints an
unnecessary blank line, and fails to properly terminate the output
line. Some implementations may require a terminating "\n" for valid
output.
printf("Value of a is %d\n", a);
retrun 0;
It's spelled "return". Sure, it's a minor error, but one that you
couldn't have made if you'd bothered to compile your code before
posting it. (Some of my own dumbest mistakes here have been the
result of assuming I could just write code off the top of my head
without bothering to compile it.)
}
---------------Desired OUTPUT -----------
Value of a is 20
Problem Statement
-----------------------
In the above code, at all the places where you see "?????" you have to
write some C Code.
you have to write the code such that without modifying the variable
"a" in main, value of "a" becomes 20. That is the output of program
when run is as shown in desired output.
It's not possible for the value of a to become 20 unless you modify
it. You mean that the code shouldn't *directly* modify a.
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
It's probably better just to read about pointers in some good tutorial
or reference work, such as K&R2.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson said: sh******@gmail.com writes:
>>So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
Try to solve the following problem based on your current knowledge.
If you are able to solve it without using the pointers, you don't need
to learn.
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
main's two parameters can legally be given any name you like, but
they're traditionally called argc and argv. Calling them anything
else is obfuscation.
By that argument, these versions are obfuscated too:
int main(int ArgumentCount, char **ArgumentVector)
int main(int CommandLineArgCount, char **CommandLineArgument)
Longwinded they may be, but I don't agree that they are obfuscated.
And since you don't use them, you can omit them,
declaring main as "int main(void)".
Quite so.
<snip>
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from.
Neither do I, but it is well-established, rather like void main.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
sh******@gmail.com writes:
>printf("\n Value of a is %d",a);
You have a call to printf. Where's the required #include <stdio.h>?
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from. This prints an
unnecessary blank line, and fails to properly terminate the output
line.
At the beginning? It might be at the end of previous line, as in:
for(i=1; i<=10; ++i)
printf("%d ",i);
printf("\nNext line...");
Or serves to separate the program output from whatever preceded it on the
console. Or to guarantee to start at the beginning of a line where the
previous output is not known.
So hardly bizarre.
--
Bartc
* *printf("\n Value of a is %d",a);
>
You have a call to printf. *Where's the required #include <stdio.h>?
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from. *This prints an
unnecessary blank line, and fails to properly terminate the output
line. *
Printing a blank line in beginning might be personal preference too,
but i certainly would like to know
what causes failure to properly terminate the output line.
It's spelled "return". *Sure, it's a minor error, but one that you
couldn't have made if you'd bothered to compile your code before
posting it. *(Some of my own dumbest mistakes here have been the
result of assuming I could just write code off the top of my head
without bothering to compile it.)
yea, i didn't compile before posting. My mistake. I will take care of
it in future.
you have to write the code such that without modifying the variable
"a" in main, value of "a" becomes 20. That is the output of program
when run is as shown in desired output.
It's not possible for the value of a to become 20 unless you modify
it. *You mean that the code shouldn't *directly* modify a.
I mentioned without modifying the variable "a" in main. Probably I
should have been more specific here by saying
you have to write the code such that
- you do not modify the variable "a" in function main i.e. you can not
assign any value to variable "a" in function main
- line immediately after call to function X [printf("\n Value of a is
%d",a);] in function main should print as below
Value of a is 20
That will also stop Richard Heathfield's solution without using
pointers from being an answer to this puzzle.
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
It's probably better just to read about pointers in some good tutorial
or reference work, such as K&R2.
Did that come after seeing Richard's Solution or you think there still
can be a solution without using call by reference here. I agree call
be reference is actually call be value only in "C" but want to explore
you more on this.
--
vIpIn
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>sh******@gmail.com writes:
>>>So now I'm wondering: what's the exact position of pointers in C? Is
it really necessary to learn how it works again?
Try to solve the following problem based on your current knowledge.
If you are able to solve it without using the pointers, you don't need
to learn.
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
main's two parameters can legally be given any name you like, but
they're traditionally called argc and argv. Calling them anything
else is obfuscation.
By that argument, these versions are obfuscated too:
int main(int ArgumentCount, char **ArgumentVector)
int main(int CommandLineArgCount, char **CommandLineArgument)
Yes.
Longwinded they may be, but I don't agree that they are obfuscated.
You can obfuscate by being overly verbose as well as by being overly
terse.
If I see either
int main(int lI0O0, char **lI0OO)
or
int main(int ArgumentCount, char **ArgumentVector)
I have to stop and think about what those two identifiers mean. In
both cases, I'm going to have to realize that what they really *mean*
is argc and argv.
[...]
>I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from.
Neither do I, but it is well-established, rather like void main.
I think it's a Windows thing, but I don't know why.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Bartc" <bc@freeuk.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>sh******@gmail.com writes:
>>printf("\n Value of a is %d",a);
You have a call to printf. Where's the required #include <stdio.h>?
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from. This prints an
unnecessary blank line, and fails to properly terminate the output
line.
At the beginning? It might be at the end of previous line, as in:
for(i=1; i<=10; ++i)
printf("%d ",i);
printf("\nNext line...");
Or serves to separate the program output from whatever preceded it on
the console. Or to guarantee to start at the beginning of a line where
the previous output is not known.
So hardly bizarre.
No, the line
printf("\n Value of a is %d",a);
was the only output call in the program.
Printing "\n" at the beginning of the program's output isn't that bad,
though I see no reason for the superfluous blank line. But omitting
the "\n" at the end of the program's output, unless there's a specific
(and system-specific) reason for it, is wrong.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" sh******@gmail.com writes:
[...]
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
It's probably better just to read about pointers in some good tutorial
or reference work, such as K&R2.
Did that come after seeing Richard's Solution or you think there still
can be a solution without using call by reference here. I agree call
be reference is actually call be value only in "C" but want to explore
you more on this.
My point was merely that reading a good tutorial is a more effective
way to learn about pointers than reading a single puzzle. I haven't
really thought about other ways to "cheat" on your puzzle.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On 13 Sep, 20:17, Richard Heathfield <r...@see.sig.invalidwrote:
sh.vi...@gmail.com said:
/* Puzzle code*/
void X(?????){
???????
}
int main(int cnt, char *aa[]){
int a;
a = 5;
X(??????); * *//line # 5
printf("\n Value of a is %d",a);
retrun 0;
}
---------------Desired OUTPUT -----------
Value of a is 20
Problem Statement
-----------------------
In the above code, at all the places where you see "?????" you have to
write some C Code.
you have to write the code such that without modifying the variable
"a" in main, value of "a" becomes 20. That is the output of program
when run is as shown in desired output.
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
void X(int ignore){
* * * * int puts(const char *);
* * * * void exit(int);
* * * * puts("Value of a is 20");
* * * * exit(0);
}
You used the string literal "Value of a is 20",
which was converted to a pointer, and the
literal text "const char *" in your declaration
of puts, so I think it it not quite accurate
to say that you have 'solved' this puzzle
without using pointers.
I think this is a decent "puzzle" for
a person confused by C to think about.
Keith Thompson said:
<snip>
You can obfuscate by being overly verbose as well as by being overly
terse.
Yes, "too much" of anything is bad, just as "too little" of anything is
bad, by definition. But that doesn't mean my examples were overly verbose.
Clearly you thought they were. I disagree.
If I see either
int main(int lI0O0, char **lI0OO)
or
int main(int ArgumentCount, char **ArgumentVector)
I have to stop and think about what those two identifiers mean.
In the first case, I agree with you. In the second, I would be very
surprised to find a man of your calibre struggling with this.
In
both cases, I'm going to have to realize that what they really *mean*
is argc and argv.
No, in both cases, you're going to have to realise that what they really
*mean* is an argument count and an argument vector. Neither argc nor argv
carries any intrinsic meaning. Yes, I agree it's a convention, and yes, I
usually use those names myself, but any reasonable substitute will do just
as well.
[...]
>>I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from.
Neither do I, but it is well-established, rather like void main.
I think it's a Windows thing, but I don't know why.
It isn't. It was already well-established in 1989, and Windows 3.0 (the
first "popular" version of Windows) didn't come out until 1990 or so.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
William Pursell said:
On 13 Sep, 20:17, Richard Heathfield <r...@see.sig.invalidwrote:
>sh.vi...@gmail.com said:
<snip>
>>
Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
void X(int ignore){
int puts(const char *);
void exit(int);
puts("Value of a is 20");
exit(0);
}
You used the string literal "Value of a is 20",
which was converted to a pointer, and the
literal text "const char *" in your declaration
of puts, so I think it it not quite accurate
to say that you have 'solved' this puzzle
without using pointers.
I'm astonished that it took almost a day for this nit to be picked.
Nevertheless (if we can lose the decls by assuming the proper inclusion of
<stdio.hand <stdlib.h>) I think I've demonstrated that it's possible to
solve this problem without /learning/ about pointers - i.e. without going
to the trouble of finding out all about * and & and so on. Therefore, it
is not a good problem, because it isn't fit for purpose. It's like asking
people to write a program to sort some data, where the intent is for them
to devise a sorting algorithm for themselves (as an intellectual
exercise), but through either a misunderstanding or sheer bloodymindedness
a programmer submits nothing more sophisticated than a call to qsort (and
with a certain amount of justification, too).
Poor specifications make for unintended solutions.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
<snip>
>You can obfuscate by being overly verbose as well as by being overly
terse.
Yes, "too much" of anything is bad, just as "too little" of anything is
bad, by definition. But that doesn't mean my examples were overly verbose.
Clearly you thought they were. I disagree.
>If I see either
int main(int lI0O0, char **lI0OO)
or
int main(int ArgumentCount, char **ArgumentVector)
I have to stop and think about what those two identifiers mean.
In the first case, I agree with you. In the second, I would be very
surprised to find a man of your calibre struggling with this.
I don't have to struggle with it. What I would have to struggle with
(just a little bit, just briefly) is why the programmer chose to use
those names rather than the almost universally conventional "argc" and
"argv".
And, for that matter, if I saw a reference to ArgumentCount in the
body of main without having noticed the unconventional declaration, I
*would* have to struggle with it. And the parameter list probably
wouldn't be the first place I'd look. If I see a reference to argc, I
don't have to look for the declaration (unless I suspect the author of
being deliberately perverse).
>In
both cases, I'm going to have to realize that what they really *mean*
is argc and argv.
No, in both cases, you're going to have to realise that what they really
*mean* is an argument count and an argument vector. Neither argc nor argv
carries any intrinsic meaning. Yes, I agree it's a convention, and yes, I
usually use those names myself, but any reasonable substitute will do just
as well.
Do you *ever* use any other names? If so, why?
The names "argc" and "argv" are not mandated by the language, as, say,
"int" and "main" are. Nevertheless, they're effectively what the
arguments to main are called. Calling them ArgumentCount and
ArgumentVector isn't quite as bad as:
#define ProgramEntryPoint main
#define DefaultIntegerType int
#define NoArguments void
DefaultIntegerType ProgramEntryPoint(NoArguments) { /* ... */ }
but it's a very similar kind of obfuscation.
[...]
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson <ks***@mib.orgwrites:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:
<snip>
>>You can obfuscate by being overly verbose as well as by being overly
terse.
Yes, "too much" of anything is bad, just as "too little" of anything is
bad, by definition. But that doesn't mean my examples were overly verbose.
Clearly you thought they were. I disagree.
>>If I see either
int main(int lI0O0, char **lI0OO)
or
int main(int ArgumentCount, char **ArgumentVector)
I have to stop and think about what those two identifiers mean.
In the first case, I agree with you. In the second, I would be very
surprised to find a man of your calibre struggling with this.
I don't have to struggle with it. What I would have to struggle with
(just a little bit, just briefly) is why the programmer chose to use
those names rather than the almost universally conventional "argc" and
"argv".
Agreed.
In the same way I think "if(0==funcCall(t))" is too clever for its own
good and a tad pretentious.
And
p = malloc(2 * sizeof h[i])
is liable to confuse many over
p = malloc(2 * sizeof h[0])
or even better
p = malloc(sizeof structArr[0]);
[argc, argv]
Keith Thompson said:
<snip>
Do you *ever* use any other names? If so, why?
No, I can't say I do, being a bit of a traditionalist - but I have no
particular reason not to, other than mere tradition.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson wrote:
sh******@gmail.com writes:
[...]
>>>Once you finish this, you will realize that there are many cases/
problems which cann;t be solved without using the pointers.
It's probably better just to read about pointers in some good tutorial
or reference work, such as K&R2.
Did that come after seeing Richard's Solution or you think there still
can be a solution without using call by reference here. I agree call
be reference is actually call be value only in "C" but want to explore
you more on this.
My point was merely that reading a good tutorial is a more effective
way to learn about pointers than reading a single puzzle. I haven't
really thought about other ways to "cheat" on your puzzle.
I think it's the puzzle format that is the problem. I am an experienced
C programmer with absolutely no uncertainty about what pointers are, how
to use them, and why they are useful. But I found the wording of that
puzzle so obscure that it took me 20-30 seconds to figure out what he
was driving at. I think that someone who's still in the position to ask
"what are pointers good for?" is extremely unlikely to figure it out.
Code which solves that puzzle would have been better provided as an
example, than asked for as a solution. With the example in hand as a
prototype, you could then pose a puzzle which asks for a more
complicated answer that is based on the same concept.
It's like asking
people to write a program to sort some data, where the intent is for them
to devise a sorting algorithm for themselves (as an intellectual
exercise),
You analogy is perfect but incomplete, please check below
intent
------------
to devise sorting algortithm for themesleves <==to make someone
understand the *importance* of pointers (remember it is the importance
of pointers rather than pointers itself)
task given
----------------
given a data to be sorted <====given a problem to be solved
constraints
----------------
complexity of algortihm should be O(nlogn) or lower <===solution
should have code written only at places of ??????
expectation from person
----------------
he will come up with an algorithm which probably can be any of the
algorithm with complexity O(nlogn) such as merge sort, heap sort or if
exists in the world for all conditions in O(n) complexity or even in
O(1) <===he will come up with a solution for problem using pointers
or may be if exists in the world without using pointers in "C" but
solution must meet constraints
In good amount of cases, After solving the problem one will realize
that
----------------
he has used an approach which is nothing but well known algorithm
"quicksort" or any other O(nlogn) complexity sorting algorithm
<======person has used nothing but pointers and with the given
constraints there is no solution without using pointers
but through either a misunderstanding or sheer bloodymindedness
a programmer submits nothing more sophisticated than a call to qsort (and
with a certain amount of justification, too).
But than there is someone who
-------------------------------------
calls the qsort instead of trying to find the steps of algorithm
<=====uses constant string to print the solution
and still thinks that he has
--------------------------------------
devised the best answer <===solved the problem without using
pointers.
unfortunately he later finds that
---------------------------------------------------
data was already sorted and hence the complexity of algorithm has
reached complexity O(n*n) which doesn't meet the constraint <====he
has used nothing but still a pointer to a constant string.
>
Poor specifications make for unintended solutions.
sometimes specifications are not as flawed as solutions are
--
vIpIn
On Sep 14, 5:15 pm, sh.vi...@gmail.com wrote:
It's like asking
people to write a program to sort some data, where the intent is for them
to devise a sorting algorithm for themselves (as an intellectual
exercise),
You analogy is perfect but incomplete, please check below
Whose analogy? Please leave attribute lines untouched.
<snip>
I think it's the puzzle format that is the problem. I am an experienced
C programmer with absolutely no uncertainty about what pointers are, how
to use them, and why they are useful.
may be language was not as good, i have already accepted that.
But I found the wording of that
puzzle so obscure that it took me 20-30 seconds to figure out what he
was driving at.
I will try to be better in futrue. In fact i tried to improve the
wording of
problem also in one of my earlier posts.
I think that someone who's still in the position to ask
"what are pointers good for?" is extremely unlikely to figure it out.
Code which solves that puzzle would have been better provided as an
example, than asked for as a solution.
in the original post, person has mentioned that "I found that all the
code
I wrote in C contains little pointers, obviously I avoid using them "
so i assumed that he has at least used pointers in past and he will be
able to
realize the importance in the attempt to find the solution for this
problem.
prototype, you could then pose a puzzle which asks for a more
complicated answer that is based on the same concept.
yea that can also be a good approach too. I ll take a note of it.
at the end of all this discussion i hope the person, who needs to
be benefited, one who posted the query originally, is getting
benefited.
thnx all for your valuable inputs
--
vIpIn
On Sep 14, 10:35*pm, sh.vi...@gmail.com wrote:
I think it's the puzzle format that is the problem. I am an experienced
C programmer with absolutely no uncertainty about what pointers are, how
to use them, and why they are useful.
*may be language was not as good, i have already accepted that.
But I found the wording of that
puzzle so obscure that it took me 20-30 seconds to figure out what he
was driving at.
I will try to be better in futrue. In fact i tried to improve the
wording of
problem also in one of my earlier posts.
I think that someone who's still in the position to ask
"what are pointers good for?" is extremely unlikely to figure it out.
Code which solves that puzzle would have been better provided as an
example, than asked for as a solution.
in the original post, person has mentioned that "I found that all the
code
I wrote in C contains little pointers, obviously I avoid using them *"
so i assumed that he has at least used pointers in past and he will be
able to
realize the importance in the attempt to find the solution for this
problem.
prototype, you could then pose a puzzle which asks for a more
complicated answer that is based on the same concept.
yea that can also be a good approach too. I ll take a note of it.
at the end of all this discussion i hope the person, who needs to
be benefited, one who posted the query originally, is getting
benefited.
thnx all for your valuable inputs
--
vIpIn
Today I tried pointers again. It's more easier than what I've thought
before, and powerful!
Too glad to realize this:pointers makes my eyes brighten, really.
BTW: I've to admit that usernet is a strange place, first I want to
know your opinions about pointers, but now all of you are discussing
programing format or anything like that. That's really strange.
Yee.Chuang said:
<snip>
Today I tried pointers again. It's more easier than what I've thought
before, and powerful!
Too glad to realize this:pointers makes my eyes brighten, really.
They are easier than they at first seem. The most difficult thing to grasp
about pointers (and it /is/ difficult to grasp this) is that they are
really quite simple.
BTW: I've to admit that usernet is a strange place, first I want to
know your opinions about pointers, but now all of you are discussing
programing format or anything like that. That's really strange.
There is a party game called "Chinese Whispers", in which the first player
quietly and secretly reads a written phrase, and then whispers the phrase
into the ear of the next player, who whispers what he hears into the ear
of the third player, and so on. The last player says out loud what he
heard whispered into his ear, and it is compared with the written phrase.
It is often hilariously different.
What happens in Usenet threads is very similar, except that the
"corruption" comes not from slight mis-hearing but either from slight
misunderstanding or a desire on the part of one or more contributors to
focus on a side issue that arose during discussion of the principal topic
of the thread. This isn't necessarily undesirable, and some quite
fascinating discussions can be started in this way. Due to the threaded
nature of the medium, this can happen in parallel with discussions on the
original topic, so it's not as if anything is lost - but it can seem a
little confusing at first.
In this case, someone posed a "puzzle" which was presumably intended to
help the solver to understand pointers a little better (and was thus
topical), but it merely prompted a discussion on whether this "puzzle"
idea was a good way to explain pointers. If you ignore the articles
involved in the "topic drift" and look only at the first article (the
"OP") and the last one to which you replied, you get a similar effect to
that of the "Chinese Whispers" game.
Bottom line: ignore the topic drift if you like, practise with pointers,
observe your implementation's diagnostic messages, and ask when you don't
understand and your textbook seems to be of little or no help. In this
way, you should soon be in a position to use pointers in very creative and
powerful ways.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Sep 15, 5:10*pm, Richard Heathfield <r...@see.sig.invalidwrote:
Yee.Chuang said:
BTW: I've to admit that usernet is a strange place, first I want to
know your opinions about pointers, but now all of you are discussing
programing format or anything like that. That's really strange.
There is a party game called "Chinese Whispers", in which the first player
quietly and secretly reads a written phrase, and then whispers the phrase
into the ear of the next player, who whispers what he hears into the ear
of the third player, and so on. The last player says out loud what he
heard whispered into his ear, and it is compared with the written phrase.
It is often hilariously different.
What happens in Usenet threads is very similar, except that the
"corruption" comes not from slight mis-hearing but either from slight
misunderstanding or a desire on the part of one or more contributors to
focus on a side issue that arose during discussion of the principal topic
of the thread. This isn't necessarily undesirable, and some quite
fascinating discussions can be started in this way. Due to the threaded
nature of the medium, this can happen in parallel with discussions on the
original topic, so it's not as if anything is lost - but it can seem a
little confusing at first.
In this case, someone posed a "puzzle" which was presumably intended to
help the solver to understand pointers a little better (and was thus
topical), but it merely prompted a discussion on whether this "puzzle"
idea was a good way to explain pointers. If you ignore the articles
involved in the "topic drift" and look only at the first article (the
"OP") and the last one to which you replied, you get a similar effect to
that of the "Chinese Whispers" game.
Bottom line: ignore the topic drift if you like, practise with pointers,
observe your implementation's diagnostic messages, and ask when you don't
understand and your textbook seems to be of little or no help. In this
way, you should soon be in a position to use pointers in very creative and
powerful ways.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Thanks, Richard. Nice explaining, I Googled wikipedia to see how they
explain Usenet, yours is more interesting.
It seems that you treat Usenet as a game more than anything else, it's
really fun to know that it has a name called "Chinese Whispers". I
know many Chinese, they seldom play such kind of game. Now the most
popular one is "The Game of Killing" or "The Moment of Truth".
Anyway, Usenet is more than a game.
Yee.Chuang said:
<snip>
Thanks, Richard. Nice explaining, I Googled wikipedia to see how they
explain Usenet, yours is more interesting.
It seems that you treat Usenet as a game more than anything else,
No, I treat it as a way of learning and teaching. Fun, yes. Game, no.
it's
really fun to know that it has a name called "Chinese Whispers".
It doesn't. That was merely an analogy.
Anyway, Usenet is more than a game.
Strange but true.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Sep 11, 10:21*am, Stephen Sprunk <step...@sprunk.orgwrote:
That's pretty much what happened with me; I came from a Pascal
background where I had used pointers once or twice in several years, and
before that BASIC, which didn't even have the concept at all.
Sure it did/does. Look up "VARPTR."
REH sh******@gmail.com wrote, On 14/09/08 02:40:
Please leave in the attribution lines. The bit that says who wrote what
like the above.
>> printf("\n Value of a is %d",a);
You have a call to printf. Where's the required #include <stdio.h>?
I don't know where this bizarre habit of putting the "\n" at the
beginning of a line rather than at the end came from. This prints an
unnecessary blank line, and fails to properly terminate the output
line.
Printing a blank line in beginning might be personal preference too,
but i certainly would like to know
what causes failure to properly terminate the output line.
<snip>
Not having a linefeed at the end of the last line output by the program
is (on some systems) failing to properly terminate the output. Two
common results of doing this are having the prompt appear on the end of
the line, e.g. seeing as the output:
Value of a is 20markg@brenda $
Or the last line of output being overwritten so the user does not see it.
--
Flash Gordon
"Yee.Chuang" <mc*******@gmail.comwrote:
On Sep 12, 11:45=A0pm, Richard<rgr...@gmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrites:
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. =A0Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations not
met by C.
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
Hey, Richard, it's not so serious about that so called "atrocious
advice". I came here for your advise. Thanks for all of your
instructions, now I know more about points than I used to do, that's
great and fun.
There was no malice in their discussions.
I think you'll find that there _is_ malice in Richard NoSurname's
discussions. For what it's worth, in this case, he's talking complete
nonsense, and Chuck Falconer is correct (with the proviso that you want
_real_ Pascal, not Extended Pascal let alone Turbo Pascal, and that
something like Modula may be even better depending on circumstances.)
Richard
Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
>Richard wrote:
>>CBFalconer <cb********@yahoo.comwrites:
... snip ...
>>>
If C pointers are bothering you, you might consider first
learning Pascal and handling pointers therein. Then returning
to C would mean abandoning the safety and adding new
capabilities.
That is atrocious advice. And would certainly lead to
expectations not met by C.
Except that it duplicates my experience of long long ago, and I
have no problems with C pointers.
Of long long ago.
I have experience of new C programmers and have never, ever had a
problem explaining them pointers and de referencing pointers. I
tend to use a debugger a block of memory. Easy.
They do not need to learn a dead language like Pascal to
understand pointers.
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.
It is even intrinsically more portable than C.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
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?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
"Yee.Chuang" <mc*******@gmail.comwrote:
>On Sep 12, 11:45=A0pm, Richard<rgr...@gmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrites:
If C pointers are bothering you, you might consider first learning
Pascal and handling pointers therein. =A0Then returning to C would
mean abandoning the safety and adding new capabilities.
That is atrocious advice. And would certainly lead to expectations not
met by C.
Anyway outside of c.l.c pointers are easily taught. They are an address
where some data is. You can de-reference that address to get the data
there. You can advance the pointer to point to different addresses.
Trivial stuff when you do not try to be too clever and blind the poor
nOOB with ridiculous nonsense not applicable to their system at too
early a stage.
Hey, Richard, it's not so serious about that so called "atrocious
advice". I came here for your advise. Thanks for all of your
instructions, now I know more about points than I used to do, that's
great and fun.
There was no malice in their discussions.
I think you'll find that there _is_ malice in Richard NoSurname's
discussions. For what it's worth, in this case, he's talking complete
nonsense, and Chuck Falconer is correct (with the proviso that you
want
Incorrect. I think Falconers advice was atrocious. However, having seen
some people explain pointers I can see why some might even want to move
to Pascal and ignore C altogether.
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. THEN you can move into the platform independence etc.
_real_ Pascal, not Extended Pascal let alone Turbo Pascal, and that
something like Modula may be even better depending on circumstances.)
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: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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,...
| | |
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,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
