What's the position of pointers

[Bartc]

(e-mail address removed) writes:

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.

 

[sh.vipin]

   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.

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.

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.

 

[Keith Thompson]

Keith Thompson 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[]){

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.

[...]

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]

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]

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]

Keith Thompson said:



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.


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).

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.

[...]

 

[Richard]

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)

is liable to confuse many over

p = malloc(2 * sizeof h[0])

or even better

p = malloc(sizeof structArr[0]);

 

[James Kuyper]

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 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

Poor specifications make for unintended solutions.

sometimes specifications are not as flawed as solutions are

 

[vippstar]

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

 

[Yee.Chuang]

 may be language was not as good, i have already accepted that.


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.



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.


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

Today I tried pointers again. It's more easier than what I've thought
before, and powerful!
Too glad to realize thisointers 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]

Yee.Chuang said:

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.

 

[REH]

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

 

[Flash Gordon]

(e-mail address removed) wrote, On 14/09/08 02:40:

Please leave in the attribution lines. The bit that says who wrote what
like the above.

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.

 

[Richard Bos]

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

 

[CBFalconer]

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.

 

[Keith Thompson]

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?

 

[Richard]

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

--

 

[CBFalconer]

I won't argue any of those points; they're either correct or matters
of personal opinion. But ...


What exactly does "intrinsically more portable" mean?

For example, it isn't restricted to machines that operate on binary
power word lengths. It can run on decimal machines. In general
there are far fewer restrictions, yet it is quite possible for the
programmer to impose more restrictions. I am talking about systems
that meet ISO 7185 or ISO 10206. Not Turbo. Since there are many
machines without Pascal compilers, in practice it is less portable
than C.