-
-
Re: Good Tutorials
Amkcoder said:
They really are tutorials. L_BitWise.zip contains one text file, 157 lines
long, which is indeed a tutorial on bitwise operators. L_ptr2.zip contains
one text file, L_ptr.txt, which is a 174-line tutorial on pointers.
I didn't look very closely at either of them, but the first paragraph of
the pointer tute does not look promising:
"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 <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
-
Re: Good Tutorials
Ben Bacarisse said:
<snip>Richard Heathfield <rjh@see.sig.in validwrites:
>>>>"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."
>>>><snip>>>>
>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]?
>One of yours (the first one), and my second is a rather harsher take on the>
[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!).
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 <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
Comment
-
Re: Good Tutorials
"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:3-2dnbxlILFwYEXVR VnygwA@bt.com.. .Ben Bacarisse said:
>>Richard Heathfield <rjh@see.sig.in validwrites:This is exactly the point MisterE was making.<snip>>>>>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.
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.
--
Bartc
Comment
-
Re: Good Tutorials
On Sep 23, 6:09 pm, "Bartc" <b...@freeuk.co mwrote:
<snip>
I doubt you've used pointers effectively.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: <Xzryk.56633$E4 1.19305@text.ne ws.virginmedia. com>
Bartc said:Now, if you don't understand types, and those who are so trivial, Ivippstar 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.
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.
Comment
-
Re: Good Tutorials
On Sep 23, 8:33 am, vipps...@gmail. com wrote:Why don't you explain why I am wrong then, MR.PROGRAMMER,On Sep 23, 6:09 pm, "Bartc" <b...@freeuk.co mwrote:
>
<snip>
>>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.
>
Message-ID: <Xzryk.56633$E4 1.19305@text.ne ws.virginmedia. com>
Bartc 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.
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.
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.
So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...
Go on and explain,
or you are no programmer.
Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.
Comment
-
Re: Good Tutorials
On Sep 23, 8:33 am, vipps...@gmail. com wrote:Why don't you explain why I am wrong then, MR.PROGRAMMER,On Sep 23, 6:09 pm, "Bartc" <b...@freeuk.co mwrote:
>
<snip>
>>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.
>
Message-ID: <Xzryk.56633$E4 1.19305@text.ne ws.virginmedia. com>
Bartc 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.
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.
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.
So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...
Go on and explain,
or you are no programmer.
Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.
Comment
-
Re: Good Tutorials
On Sep 23, 8:33 am, vipps...@gmail. com wrote:Why don't you explain why I am wrong then, MR.PROGRAMMER,On Sep 23, 6:09 pm, "Bartc" <b...@freeuk.co mwrote:
>
<snip>
>>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.
>
Message-ID: <Xzryk.56633$E4 1.19305@text.ne ws.virginmedia. com>
Bartc 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.
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.
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.
So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...
Go on and explain,
or you are no programmer.
Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.
Comment
-
Re: Good Tutorials
"Bartc" <bc@freeuk.comw rites:
[...]But it could well stop you from communicating effectively about them.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.
And I think you overestimate your own ignorance. For example, given:
int x;
int *obj = &x;
I think you know that obj is an object (and a variable), &x is a
value, and int* is a type.
--
Keith Thompson (The_Other_Keit h) kst-u@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"
Comment
-
Re: Good Tutorials
Amkcoder wrote:
....So, if we haveThe 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."
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.
....I'm a real programmer. At least, they pay me to write computerLike I said, good tutorials...
Please only sincere students or real programmers comment,
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.
Comment
-
Re: Good Tutorials
On Sep 23, 9:03 am, jameskuy...@ver izon.net wrote:Sorry,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.
when you declare a short int it allocates two bytes and associates the
beginning of the
address to the two bytes to your variable.
And I do understand that a pointer can be refered to space allocated
by a call to malloc,
It is in my tutorial.
short int *sint=malloc(2) ;
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*si nt);
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.
Comment
-
Re: Good Tutorials
On Tue, 23 Sep 2008 09:50:21 -0700, Amkcoder wrote:
I am not qualified to discuss this topic, but will point out that yourThe reason universities, who make real programmers, use the definition
that a pointer
posts seem to be posted 2 or 3 times each.
sf
Comment
-
Re: Good Tutorials
Amkcoder said:
<snip>
You have been shown several counterexamples . Here are a few to refresh yourThe reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.
memory:
malloc(256)
myarray + offset
&integerobje ct
printf
None of these pointers is a variable that holds the address of another
variable. So now you have three choices:
1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.
1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.
Not true. For example, here's a declaration of a pointer that doesn'tThis is because every time you declare a pointer it allocates enough
bytes to hold
a value,
allocate any bytes at all:
extern int *p;
<snip>
Why? You have not yet convinced me that you have the slightest idea whatSo he's is an expert?
Then call me the professional.
you're talking about.
--
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
Comment
-
Re: Good Tutorials
On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:A byte, typicaly, as the most common systems I have used is 8-bits inAmkcoder said:
>
<snip>
>>The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.
You have been shown several counterexamples . Here are a few to refresh your
memory:
>
malloc(256)
myarray + offset
&integerobje ct
printf
>
None of these pointers is a variable that holds the address of another
variable. So now you have three choices:
>
1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.
>
1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.
>>This is because every time you declare a pointer it allocates enough
bytes to hold
a value,
Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:
>
extern int *p;
>
<snip>
>>So he's is an expert?
Then call me the professional.
Why? You have not yet convinced me that you have the slightest idea what
you're talking about.
>
--
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
length.
As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.
This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386, or the newer ones:
PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:
#include <stdio.h>
int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(shor t int));
system("pause") ;
}
Comment
-
Re: Good Tutorials
On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:A byte, typicaly, as the most common systems I have used is 8-bits inAmkcoder said:
>
<snip>
>>The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.
You have been shown several counterexamples . Here are a few to refresh your
memory:
>
malloc(256)
myarray + offset
&integerobje ct
printf
>
None of these pointers is a variable that holds the address of another
variable. So now you have three choices:
>
1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.
>
1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.
>>This is because every time you declare a pointer it allocates enough
bytes to hold
a value,
Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:
>
extern int *p;
>
<snip>
>>So he's is an expert?
Then call me the professional.
Why? You have not yet convinced me that you have the slightest idea what
you're talking about.
>
--
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
length.
As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.
This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386, or the newer ones:
PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:
#include <stdio.h>
int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(shor t int));
system("pause") ;
}
Comment
Comment