Good Tutorials

[Amkcoder]

http://amkcoder.fileave.com/L_BitWise.zip
http://amkcoder.fileave.com/L_ptr2.zip

 

[MisterE]

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

Yeah sounds like its written for people who actually want to get stuff
done, instead of written for people who want to be anal over definitions.

 

[Ben Bacarisse]

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

 

[Bartc]

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.

This is exactly the point MisterE was making.

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.

 

[Amkcoder]

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

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."
http://www.eskimo.com/~scs/cclass/notes/sx10.html, even at
universities.
Using memory external to a program, is sometimes also necessary, like
writing directly to video memory, or using the DOS inter application
communication
are, are is said here:
http://www.osdata.com/system/physical/lowmem.htm#usercommo

ARE YOU GUYS EVEN PROGRAMMERS?
You could not point out why when you said I was wrong.

Like I said, good tutorials...
Please only sincere students or real programmers comment,
others just waste space...

 

[Amkcoder]

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

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."
http://www.eskimo.com/~scs/cclass/notes/sx10.html, even at
universities.
Using memory external to a program, is sometimes also necessary, like
writing directly to video memory, or using the DOS inter application
communication
are, are is said here:
http://www.osdata.com/system/physical/lowmem.htm#usercommo

ARE YOU GUYS EVEN PROGRAMMERS?
You could not point out why when you said I was wrong.

Like I said, good tutorials...
Please only sincere students or real programmers comment,
others just waste space...

 

[vippstar]

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.

 

[Amkcoder]

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.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
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.

 

[Amkcoder]

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.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
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.

 

[Amkcoder]

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.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
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.

 

[Keith Thompson]

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.

But it could well stop you from communicating effectively about them.

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.

 

[jameskuyper]

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]

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

 

[Amkcoder]

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

 

[Amkcoder]

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,
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",*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.

 

[Amkcoder]

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

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
is a variable that holds the address to another variable in memory, is
because
it is.
Every time you declare a pointer space is allocated for it to hold a
value,
which will be treated as an address. This space has its own address,
just like a variable.
So that every time a pointer is declared the same amount of space is
allocated
capable of holding an address. The pointer's type merely indicates how
to treat the data it refers to when it is dereferenced.
So he is an expert,
then call me the professional.

 

[jellybean stonerfish]

The reason universities, who make real programmers, use the definition
that a pointer

I am not qualified to discuss this topic, but will point out that your
posts seem to be posted 2 or 3 times each.

sf

 

[Richard]

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

What absolute nonsense. The behaviour on a conforming system must be a
truth or it would not be conforming.

This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address". You address an object
or memory or whatever through it. One representation of that address is
as a value which can be displayed as a hexadecimal memory "address".

Why, oh why try to make C into something it is not?

The comment the other day about my "magical debugger" representing
pointers as values or 32 bit hex strings was simply astounding. As if it
was a bad thing.

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.

--

 

[jameskuyper]

On Sep 23, 9:03 am, (e-mail address removed) wrote: ....

Sorry,
but a short int is exactly two bytes,

On many machines that's true; though the standard imposes no such
requirement. There are machines where CHAR_BITS==16, and short is a
one-byte type. There are other machines where char is 8 bits, long
long is 64 bits, and all of the types between char and long long are
32 bits.

... and in order to use them they
must be treated as a
word.

On many machines that's true. On other machines they can be one word
long, or a fraction of a word. The standard imposes no requirements on
that kind of thing.

You think I don't know that you can refer a pointer to allocated
memory,
it is in my tutorial.

Then you should revise your definition of a pointer to allow for that
possibility.

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.

Yes, which need not be the address of a variable.

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

There are two different common values that code could print out, and
real machines where it will print 154 because unsigned char and short
int are both 16 bits long, and real machines where it will print
garbage, or possibly simply abort, because all integer types between
(but not including) 'char' and 'long long' are 4 bytes long.

None of which proves that the value of sint points at a variable. Your
point is?

They must pay you minimum wage just to crank out code.

I'm no longer allowed to use the tax tables when computing my federal
taxes; they don't go high enough. In my profession, that doesn't
indicate an unusually high salary. In fact, my salary is below the
level you might expect from my education and experience levels,
because non-military scientific computer programming doesn't tend to
pay as well as military or commercial programming.

I am a real programmer, 14 years in the making.

I've got 34 years of experience, myself.