What's the position of pointers

[Yee.Chuang]

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

[William Pursell]

On 13 Sep, 20:17, Richard Heathfield <[e-mail].i nvalidwrote:

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.

[Richard Heathfield]

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 **ArgumentVecto r)
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

[Richard Heathfield]

William Pursell said:

On 13 Sep, 20:17, Richard Heathfield <[e-mail].i nvalidwrote:

>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 misunderstandin g or sheer bloodymindednes s
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

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

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 **ArgumentVecto r)
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 ProgramEntryPoi nt main
#define DefaultIntegerT ype int
#define NoArguments void

DefaultIntegerT ype ProgramEntryPoi nt(NoArguments) { /* ... */ }

but it's a very similar kind of obfuscation.

[...]

--
Keith Thompson (The_Other_Keit h) 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"

[Richard]

Keith Thompson <ks***@mib.orgw rites:

Richard Heathfield <rj*@see.sig.in validwrites:

>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 **ArgumentVecto r)
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]);

[Richard Heathfield]

[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

[James Kuyper]

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.

[sh.vipin]

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 misunderstandin g or sheer bloodymindednes s
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

[vippstar]

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>

[sh.vipin]

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