"A pointer in C is a variable which holds the address of another variable
in memory. They are useful for dynamicly allocated memory which may be
deallocated when nolonger needed,linked lists,writing to memory external to
the program,and allowing invoked functions to manipulate the data of
variables outside their scope. These have many uses and are necessary to
successfull programming in C."
Oh deary deary me.
Richard Heathfield said:MisterE said:
People who take the time to learn their subject properly are more likely to
get more stuff done more quickly than people who just grab a screwdriver
and start poking around at random.
Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.
Richard Heathfield said:Ben Bacarisse said:
Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.
I count only 2 and half. Why not tell us your three[1]?[1] Mine are: a pointer is a value not a variable. They address
objects not variables (that, to me, is the half) and I don't like the
idea of "memory external to the program". If you have a pointer you
can write though, it is your data (even if the OS wishes it were
not!).
One of yours (the first one), and my second is a rather harsher take on
the
same subject as your one-and-a-halfth point, because pointer values need
not even represent object addresses, let alone variable addresses - they
could be indeterminate, or null, or function pointers. My third rather
depends on what you mean by "variable", but if the last clc discussion on
the matter is anything to go by, the bit about scope is wrong too.
Richard Heathfield said:MisterE said:People who take the time to learn their subject properly are more likely to
get more stuff done more quickly than people who just grab a screwdriver
and start poking around at random.Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.
I count only 2 and half. Why not tell us your three[1]?
Interesting fact from my teaching: I'd explain some concept to student
A carefully using all the right terms. Because both the concept and
terms are new, students A looks a little baffled. Before I can have
another go, student B -- listen in -- repeats what I have said in
different (more common) words thereby introducing several technical
errors. Student A goes "Ah, I get it" and repeats it using yet more
terms with yet more errors of fact. I used not to walk away in my
early years but I soon learnt it was better to walk away saying
"that's the gist of it" and making a note to correct some of the
technical details later.
Now, a tutorial is different, but it may later correct this sloppy
start.
[1] Mine are: a pointer is a value not a variable. They address
objects not variables (that, to me, is the half) and I don't like the
idea of "memory external to the program". If you have a pointer you
can write though, it is your data (even if the OS wishes it were
not!).
Richard Heathfield said:MisterE said:People who take the time to learn their subject properly are more likely to
get more stuff done more quickly than people who just grab a screwdriver
and start poking around at random.Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.
I count only 2 and half. Why not tell us your three[1]?
Interesting fact from my teaching: I'd explain some concept to student
A carefully using all the right terms. Because both the concept and
terms are new, students A looks a little baffled. Before I can have
another go, student B -- listen in -- repeats what I have said in
different (more common) words thereby introducing several technical
errors. Student A goes "Ah, I get it" and repeats it using yet more
terms with yet more errors of fact. I used not to walk away in my
early years but I soon learnt it was better to walk away saying
"that's the gist of it" and making a note to correct some of the
technical details later.
Now, a tutorial is different, but it may later correct this sloppy
start.
[1] Mine are: a pointer is a value not a variable. They address
objects not variables (that, to me, is the half) and I don't like the
idea of "memory external to the program". If you have a pointer you
can write though, it is your data (even if the OS wishes it were
not!).
I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.
Message-ID: said:vippstar said: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.
I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.
I doubt you've used pointers effectively.
vippstar said: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.
Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.
I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.
I doubt you've used pointers effectively.
vippstar said: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.
Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.
I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.
I doubt you've used pointers effectively.
vippstar said: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.
Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.
Bartc said:I neither know nor care whether a pointer is a value, variable, type
or object. But that hasn't stopped me using them quite effectively.
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
Like I said, good tutorials...
Please only sincere students or real programmers comment,
Amkcoder wrote:
...
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
So, if we have
char greeting[] = "Hello, World!";
int seven = 7;
Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.
I consider this to be a serious defect in your definition of a
pointer.
...
Like I said, good tutorials...
Please only sincere students or real programmers comment,
I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.
Amkcoder wrote:
...
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
So, if we have
char greeting[] = "Hello, World!";
int seven = 7;
Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.
I consider this to be a serious defect in your definition of a
pointer.
...
Like I said, good tutorials...
Please only sincere students or real programmers comment,
I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.
Amkcoder wrote:
...
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
So, if we have
char greeting[] = "Hello, World!";
int seven = 7;
Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.
I consider this to be a serious defect in your definition of a
pointer.
...
Like I said, good tutorials...
Please only sincere students or real programmers comment,
I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.
Amkcoder said:
Amkcoder wrote:
...
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
So, if we have
char greeting[] = "Hello, World!";
int seven = 7;
Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.
I consider this to be a serious defect in your definition of a
pointer.
...
Like I said, good tutorials...
Please only sincere students or real programmers comment,
I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.Sorry,
but a short int is exactly two bytes,
No, a short int is at least 16 bits, and at least one byte, in width, but
there is no upper limit.
and in order to use them they
must be treated as a
word.
No, they must be treated as short ints (modulo object representation
techniques which don't seem to be relevant here).
You think I don't know that you can refer a pointer to allocated
memory,
it is in my tutorial.
He's not saying you don't know that. He's saying your definition of a
pointer fails to take it into account.
When you declare a short int the compiler allocates two bytes for it
No, when you *define* a short int, the implementation allocates
sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
To prove you wrong I will show you the following:
short int *sint=malloc(2);
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*sint);Check out the value it prints out...
You appear to think that the behaviour you observe on your system
represents fundamental truths about C. It doesn't.
They must pay you minimum wage just to crank out code.
I am a real programmer, 14 years in the making.
How nice. But you would do well to listen to James. He's what they call an
"expert".
--
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
Amkcoder said:
Amkcoder wrote:
...
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."
So, if we have
char greeting[] = "Hello, World!";
int seven = 7;
Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.
I consider this to be a serious defect in your definition of a
pointer.
...
Like I said, good tutorials...
Please only sincere students or real programmers comment,
I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.Sorry,
but a short int is exactly two bytes,
No, a short int is at least 16 bits, and at least one byte, in width, but
there is no upper limit.
and in order to use them they
must be treated as a
word.
No, they must be treated as short ints (modulo object representation
techniques which don't seem to be relevant here).
You think I don't know that you can refer a pointer to allocated
memory,
it is in my tutorial.
He's not saying you don't know that. He's saying your definition of a
pointer fails to take it into account.
When you declare a short int the compiler allocates two bytes for it
No, when you *define* a short int, the implementation allocates
sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
To prove you wrong I will show you the following:
short int *sint=malloc(2);
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*sint);Check out the value it prints out...
You appear to think that the behaviour you observe on your system
represents fundamental truths about C. It doesn't.
They must pay you minimum wage just to crank out code.
I am a real programmer, 14 years in the making.
How nice. But you would do well to listen to James. He's what they call an
"expert".
--
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
The reason universities, who make real programmers, use the definition
that a pointer
Amkcoder said:Amkcoder said:
On Sep 23, 9:03 am, (e-mail address removed) wrote:
Amkcoder wrote:
The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."So, if we havechar greeting[] = "Hello, World!";
int seven = 7;Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.I consider this to be a serious defect in your definition of a
pointer.
Like I said, good tutorials...
Please only sincere students or real programmers comment,I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.Sorry,
but a short int is exactly two bytes,
No, a short int is at least 16 bits, and at least one byte, in width, but
there is no upper limit.
and in order to use them they
must be treated as a
word.
No, they must be treated as short ints (modulo object representation
techniques which don't seem to be relevant here).
You think I don't know that you can refer a pointer to allocated
memory,
it is in my tutorial.
He's not saying you don't know that. He's saying your definition of a
pointer fails to take it into account.
When you declare a short int the compiler allocates two bytes for it
No, when you *define* a short int, the implementation allocates
sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
To prove you wrong I will show you the following:
short int *sint=malloc(2);
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*sint);Check out the value it prints out...
You appear to think that the behaviour you observe on your system
represents fundamental truths about C. It doesn't.
The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.
This is because every time you declare a pointer it allocates enough
bytes to hold
a value, which will be treated as an address, and this space has its
own address just like a
variable.
The only difference is for each pointer declared, it is usually the
same amount
of bytes allocated to hold the address. The type of the pointer merely
indicates how the compiler should treat the data pointed by the
address
stored in the pointer when it is dereferenced.
The compiler knows to do this because it knows you declared a pointer
and not
a ordinary variable.
So he's is an expert?
Then call me the professional.
Amkcoder said:On Sep 23, 9:03 am, (e-mail address removed) wrote: ....
Sorry,
but a short int is exactly two bytes,
... and in order to use them they
must be treated as a
word.
You think I don't know that you can refer a pointer to allocated
memory,
it is in my tutorial.
When you declare a short int the compiler allocates two bytes for it
(a word),
and associates that address to the variable name.
This can be done manually with a call to malloc, which will return the
address
to the first byte to your allocated space.
To prove you wrong I will show you the following:
short int *sint=malloc(2);
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*sint);
Check out the value it prints out...
They must pay you minimum wage just to crank out code.
I am a real programmer, 14 years in the making.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.