Good Tutorials

[Andrew Poelstra]

Re: Good Tutorials

On 2008-09-23, Amkcoder <frontal_lobe_d estroyer@yahoo. comwrote:

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") ;
}

On my system, it does indeed output 666, followed by a "command
not found" regarding your system() call. I'm not sure what this
code demonstrates, though, other than that one can take this:
puts("666")
And make it intrinsicly non-portable, rife with undefined
behavior, inefficient and unmaintainable to boot.

But hey, you're the expert.


(My compiler also has this to say:

usenet.c: In function ‘main’:
usenet.c:9: warning: format ‘%d’ expects type ‘int’, but argument
2 has type ‘long unsigned int’
usenet.c:10: warning: implicit declaration of function ‘system’
usenet.c:11: warning: control reaches end of non-void function

but it hasn't been dealing with C code for as long as you.)

(Also, FWIW, it's incorrect on the first warning - the value
yeilded by the sizeof operator is technically a size_t. I'm
guessing since all the world's a x86, it doesn't matter.)

--
Andrew Poelstra apoelstra@wpsof tware.net
Only GOD may divide by zero. That is how he created black holes.
-Veselin Jungic

[Keith Thompson]

Re: Good Tutorials

Andrew Poelstra <apoelstra@supe rnova.homewrite s:

On 2008-09-23, Amkcoder <frontal_lobe_d estroyer@yahoo. comwrote:

[...]

> printf("%d bytes for short int \n",sizeof(shor t int));

[...]

(My compiler also has this to say:
>
usenet.c: In function ‘main†™:
usenet.c:9: warning: format ‘%d’ expects type ‘int’ , but argument
2 has type ‘long unsigned int’

[...]

>
(Also, FWIW, it's incorrect on the first warning - the value
yeilded by the sizeof operator is technically a size_t. I'm
guessing since all the world's a x86, it doesn't matter.)

But size_t is merely a typedef for some predefined unsigned integer
type, apparently unsigned long on your system. A typedef doesn't
create a new type, merely an alias for an existing type. So on your
system, sizeof(short int) really is of type long unsigned int.

But it would be nice if the compiler were clever enough to refer to
the size_t typedef instead.


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

[Richard Heathfield]

Re: Good Tutorials

Keith Thompson said:

<snip>

Then the only disagreement/confusion is over the meaning of "uses".
An object of type short, as we all know, *occupies* exactly
sizeof(short) bytes;

Yes.

you can argue (and I won't disagree) that it only
*uses* the sign and value bits.

I would indeed argue that.

(Though it might *use* the padding
bits for some purpose other than representing the value, for example
as check bits.)

That would be an implementation detail, and a program that took advantage
of it in some way would be grossly non-portable.

If Chuck intended to make that distinction, I'll gladly concede that
he was correct, though I don't know why he'd say bytes in that context
rather than bits. But he was responding to Amkcoder's claim that a
short int *is* exactly two bytes.

Yes, perhaps that's why.

A more pertinent response to that
claim is that a short int *is* exactly sizeof(short) bytes.

Right. I pointed this out to Amkcoder, but it seems to have flown way over
his head.

>
(I doubt that Amkcoder knows about padding bits anyway.)

Here, I cannot bring myself to disagree with you.

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

[Flash Gordon]

Re: Good Tutorials

Mark L Pappin wrote, On 24/09/08 01:52:

<snip>

In an ideal world with perfectly rational students perhaps one could
begin by stating "What I am about to tell you is not completely
correct, but is a necessary simplification to bootstrap this model of
reality into your brain. Later, as your understanding grows, you will
need to throw out some of these simplifications to allow you to see
better models." We don't have such a world, unfortunately.

Some of the very good teachers I had did basically tell us that. Well,
actually it was the physics and chemistry teachers told us that the
models were simplifications and if we were doing both we would be taught
different models for different purposes in the two courses and further
models in later courses if we continued with science. It did not seem to
cause problems.
--
Flash Gordon
If spamming me sent it to smap@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Nick Keighley]

Re: Good Tutorials

On 23 Sep, 16:48, Amkcoder <frontal_lobe_d estro...@yahoo. comwrote:

On Sep 23, 8:33 am, vipps...@gmail. com wrote:

On Sep 23, 6:09 pm, "Bartc" <b...@freeuk.co mwrote:

sombody has messed up the attributions. There may have been
Top Posting. I've just gathered up the attributions I've
found in this post and dumped them here.

Message-ID: <Xzryk.56633$E4 1.19...@text.ne ws.virginmedia. com>
Bartc said:

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

>

I doubt you've used pointers effectively.

I think you're wrong. People *can* use pointers effectivly
without swallowing the standard. They might do a better
job if they fully understood the underlying type system
but not doing so does *not* preclude them from using C
effectivly.

A tutorial author though should at least be aware or the
correct terminology even if for pedalogical purposes
he drifts away from it a little.

>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 don't think he frightens easily!

:-)

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.

cobblers

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.

It might be an idea to read C documentaion when writing
a C tutorial.

So you call Intel liars,

no he didn't. Don't be silly.

You call universities who use my same definition of pointers liars,

ditto. Which universites? Where? Do you have a link to this
usage?

And then you say I have but a smattering of datatypes
when you don't even know what your saying...

your -you're

why do you think he doesn't know what he's saying?
Is he delirious? Drugged?

Go on and explain,
or you are no programmer.

silly

Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.

are you the author of the tutorial?
Bad C tutorials unfortunatly far outnumber
good ones.


--
Nick Keighley


"Perilous to us all are the devices of
an art deeper than we possess ourselves."
Gandalf The Grey (discussing Windows Vista)

[soscpd]

Re: Good Tutorials

Hello Richard, James, List

On Sep 23, 6:20 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

If you're looking for a *short* definition, "pointer" is perfect. If you're
looking for a technical definition, the best place to look is the
Standard, but unfortunately it defines "pointer" in terms of behaviour,

So far, I can't agree with you more.

"One great advantage of stored-program digital computers is that they can
store both code and data in their memory. To a first approximation, a
pointer value is a value that represents the place in memory where either
code (a function) or data (an object) is stored. We'll cover the two
exceptions - indeterminate pointers and null pointers - later on. Pointer
values can be stored in objects that have the appropriate pointer type for
the relevant object or function."

Yeah, right. It is correct. But try that in a classroom. The ones who
will not sleep, will leave the room. But ok... I'll give you a shot.
By friday I can test it with a friend (teacher... :).

My point is: There must be a way to define pointers as simple as they
are - they are pointers. They point to something. Then, the behavior
it's up to the contents. Leave pointers alone and put the effort in
teaching the contents. Doing that you will not scare students with -
Hey.. that's true, but not always - or - Pointers is a hard subject.
It is not if teached without the "stuff", I think.

++++++++

On Sep 23, 6:55 pm, jameskuy...@ver izon.net wrote:

Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

>
I'm not quite sure what you mean by those questions. A function
pointer does not "return" anything. It points at the entry point for a

Well... James... here is the part who, sometimes, make-me delete all
c.l.c inputs on my mail box before read. I love C. It is my favorite
language, and I am always looking for his edges. Still can't find (and
probably will not), but the trip is enough fun.

But every time we are discussing something on c.l.c, we must follow
the standards, thinking, speaking and so on. Well... was my mistake do
not follow that simple rules. By return, I mean: If you use it, in
some place where you expect the variable value, you will get the value
(please... no to initialization, error and stuff. Consider the utopia
with me, right now. I'm not a C teacher and my goal is not follow the
standards as standards... they are more general guidelines to me),
like:

int *p = malloc(sizeof(i nt));
p=2;

So... p is a pointer to a memory location of int size?

After all... the machine job is to go to that location and "return"
the value, if I ask for it.

That's was my return definition in there.

function, which does not qualify as an "object" as far as the C
standard is concerned. It can be used to call the function that it
points at. That is the reason why we use function pointers. The

Right. By me... that still means you are returning something. I can't
find a function who do not return (by me, a null void return is,
still, a return).

It has a value, which is the location of the function it points at. It
doesn't "return" that value.

Ok... ok...

The standard doesn't define "pointer" but it does define a "pointer
type":

Yeah, right...

Can we keep Richard's "...defines "pointer" in terms of behaviour..."
and keep that way?

It is commonplace to use the term pointer to mean either a "pointer
object" or a "pointer value", both usages are common in the standard

I can't find any difference between function pointer and variable
pointer (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use. What is
it, and how you will use it doesn't matter to the pointer. That is why
I am usual to do not mix both subjects (bottle and contents - ok...
here is not exactly bottle. Its more like the place where the bottle
is... endless). I just find that way the best one to know how to
handle pointers.

in C terms, a variable is a named object.

Mm... agreed, I think.


Regards
Rafael

[Nick Keighley]

Re: Good Tutorials

On 23 Sep, 19:03, Amkcoder <frontal_lobe_d estro...@yahoo. comwrote:

On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

Amkcoder said:

>

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

don't post sigs. The bit after "-- "

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.

this has nothing to do with C. C does not have "words".
Nowhere is is set in stone that a short must be an x86 word.
On some compilers a short might be 32 bits. Even on an
x86.

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.

there are 64-bit x86s

To program on the x86 architecture it is requisite knowledge.

no

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,

no. I have programmed x86s and I don't have an x86 hardware manual.

<snip>

You definitly should learn more C before you write any more
tutorials.


--
Nick Keighley

[Nick Keighley]

Re: Good Tutorials

On 23 Sep, 21:22, jameskuy...@ver izon.net wrote:

Amkcoder wrote:

On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

<snip>

[x86] is the most common of architectures, so to be a real programmer,

>
Don't count on it. For every x86 machine, there's multiple embedded
processors on the very same board with it, in addition to all of the
embedded processors in all of the other devices in the world. I'm not
sure that there's any one embedded processor that is more common than
the entire x86 family of processors, but collectively I'm quite sure
that embedded processors vastly outnumber x86 processors, and most of
those embedded processors have environments significantly different
from the one you describe.

the ARM is a contender. From its wiki entry:
"Today, the ARM family accounts for approximately 75% of all embedded
32-bit RISC CPUs,[1] making it one of the most widely used 32-bit
architectures."

<snip>

--
Nick Keighley

[Richard Heathfield]

Re: Good Tutorials

soscpd said:

Hello Richard, James, List
>
On Sep 23, 6:20 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
>

<snip>

>

>"One great advantage of stored-program digital computers is that they
>can store both code and data in their memory. To a first approximation,
>a pointer value is a value that represents the place in memory where
>either code (a function) or data (an object) is stored. We'll cover the
>two exceptions - indeterminate pointers and null pointers - later on.
>Pointer values can be stored in objects that have the appropriate
>pointer type for the relevant object or function."

>
Yeah, right. It is correct. But try that in a classroom.

Not word for word, of course. Although "lecture" originates from the time
when a professor would read out his notes word for word and students would
religiously copy it all down, a good teacher had better be able to sound
like he /isn't/ just reading from a book. Nevertheless, the concepts in
the above paragraph are important, and a good teacher will be able to
present them without boring the students *and* without giving them
incorrect information.

A teacher should never try to tell the whole truth (because there isn't
time), but he should certainly tell the truth and nothing but the truth.

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

Re: Good Tutorials

soscpd wrote:
....

On Sep 23, 6:55 pm, jameskuy...@ver izon.net wrote:
>

>>Mmm... did the function (pointer) return something? That is not the
>>"why" we can use function pointers?

>I'm not quite sure what you mean by those questions. A function
>pointer does not "return" anything. It points at the entry point for a

>
Well... James... here is the part who, sometimes, make-me delete all
c.l.c inputs on my mail box before read. I love C. It is my favorite
language, and I am always looking for his edges. Still can't find (and
probably will not), but the trip is enough fun.
>
But every time we are discussing something on c.l.c, we must follow
the standards, thinking, speaking and so on. Well... was my mistake do
not follow that simple rules. ...

Technical jargon serves many purposes, including the ignoble purpose of
separating the in-group and the out-group. However, it's main purpose is
to clearly communicate complex concepts (to members of the in-group).
Jargon wasn't just invented for fun; it was invented because ordinary
English doesn't express the ideas with sufficient precision. (See below
for examples.

>It is commonplace to use the term pointer to mean either a "pointer
>object" or a "pointer value", both usages are common in the standard

>
I can't find any difference between function pointer and variable
pointer

A function pointer points at a function; the function can be called
using that pointer by using the syntax pfunc(), or (*pfunc)(). An object
pointer points at an object; the value represented by that object can be
either accessed or written by using the syntax *pobj. If you don't see a
difference, how do you decide which syntax to use?

... (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use.

I suspect that you actually understand the difference those words
describe; I just think you're unclear about the fact that those words
describe that difference.

The difference is that a pointer object is a piece of memory that
contains the representation of a pointer value. A pointer value can also
occur in a C program without being stored in any object, for example, in
the expression p+3, where p is the name of a pointer variable. The
pointer value p+3 isn't necessarily stored in any object, as that term
is defined by the C standard, it typically resides in a register.

Due to optimization, that pointer value might never be stored anywhere -
p+3 might be combined with some other operation, as in (p+3)->count.
That C code might be translated into machine code which retrieves the
byte address stored in p, and then adds to it, in a single instruction,
the combined values of 3*sizeof *p and the offset of the 'count' member
within the struct pointed at by p.

The distinction between a pointer object and a pointer value is sort of
like the difference between a newspaper article describing a murder, and
the murder described by that article. If you have trouble distinguishing
between those two things, I'd recommend avoiding reading the newspaper
:-). Similarly, if you can't distinguish between a pointer object and a
pointer value, you should avoid pointers (which would make using C a bit
difficult :-).

[vippstar@gmail.com]

Re: Good Tutorials

On Sep 24, 11:12 am, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On Sep 23, 8:33 am, vipps...@gmail. com wrote:

Message-ID: <Xzryk.56633$E4 1.19...@text.ne ws.virginmedia. com>
Bartc [on another article] 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.

>

I doubt you've used pointers effectively.

>
I think you're wrong. People *can* use pointers effectivly
without swallowing the standard. They might do a better
job if they fully understood the underlying type system
but not doing so does *not* preclude them from using C
effectivly.

Since you repeated the typo twice, I'd wanted to mention it's
'effectiv*e*ly' .
I think you're wrong, but before we further argue I think it's best to
agree about the meaning of "effective use of pointers", as it's pretty
vague.

The reason I mentioned the type system, is that in another article,
someone asked how to learn pointers.
I replied with something close to "learn the type system, then read
the pointer semantics".
You certainly need to know the type system; if you do, you'll always
know what &p is, **p, the difference between &*p and *&p.
If you know the pointer semantics, you'll always know what operations
can be performed with the pointer.

[Richard]

Re: Good Tutorials

vippstar@gmail. com writes:

On Sep 24, 11:12 am, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>On Sep 23, 8:33 am, vipps...@gmail. com wrote:

Message-ID: <Xzryk.56633$E4 1.19...@text.ne ws.virginmedia. com>
Bartc [on another article] 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.

>>

I doubt you've used pointers effectively.

>>
>I think you're wrong. People *can* use pointers effectivly
>without swallowing the standard. They might do a better
>job if they fully understood the underlying type system
>but not doing so does *not* preclude them from using C
>effectivly.

>
Since you repeated the typo twice, I'd wanted to mention it's
'effectiv*e*ly' .
I think you're wrong, but before we further argue I think it's best to

No surprise there.

But you are wrong. "effective and efficient" use does not need the
knowledge of the standard since a huge % of code is never ported to
other platforms. I dont "support" writing "non standard code"
necessarily but to deny that a practical knowledge of pointers in terms
of memory addresses similar to CPU registers can produce good, stable
efficient code is purely ridiculous.

agree about the meaning of "effective use of pointers", as it's pretty
vague.
>
The reason I mentioned the type system, is that in another article,
someone asked how to learn pointers.
I replied with something close to "learn the type system, then read
the pointer semantics".
You certainly need to know the type system; if you do, you'll always
know what &p is, **p, the difference between &*p and *&p.

Neither of which have anything to do with the type system of course. e.g
I know what those things are and there's not a type in sight.

If you know the pointer semantics, you'll always know what operations
can be performed with the pointer.

Now I get it. You're just waffling for waffle's sake.

[Trent Josephsen]

Re: Good Tutorials

Mark L Pappin wrote:

CBFalconer <cbfalconer@yah oo.comwrites:
>

>I listened to the teacher, and was horrified at the inaccuracies he
>was teaching. I resolved I could do better.
>>
>So I got to try out my technique. I accurately explained various
>things. Then I looked at the class, and was greeted with
>dumbfounded looks.

...

>From then on I have been left with admiration for the way the
>demonstratin g teacher managed to explain things with inaccurate
>explanations .

>
Terry Pratchett, Ian Stewart, and Jack Cohen (in their several
"Science of Discworld" books) describe the technique as "Telling Lies
To Children", where the Lies become incrementally more accurate as the
Children's understanding becomes more complete.
>
Some Children need particularly blatant Lies and take a while to get
used to revisions, and some refuse to accept later revisions at all.
We see examples of both here.

(Almost) everything I know about pointers, I learned from K&R2.
Obviously this is not a complete understanding, but surely most would
concede that the book does a fine job? As a student, I found the
descriptions of pointers clear, concise, and unambiguous. I can only
presume accuracy, because I haven't read the Standard in its entirety.
(If I am mistaken in presuming that K&R's discussion of pointers is at
least reasonably accurate, I am fully willing to admit it.)

I agree there are times when "Lies" are necessary to build foundational
understanding (take the Bohr model of the atom, which is still taught in
schools). However, I don't think that it's necessary in this context.

[CBFalconer]

Re: Good Tutorials

soscpd wrote:

>

.... snip ...

>
I can't find any difference between function pointer and variable
pointer (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use. What
is it, and how you will use it doesn't matter to the pointer. That
is why I am usual to do not mix both subjects (bottle and contents
- ok... here is not exactly bottle. Its more like the place where
the bottle is... endless). I just find that way the best one to
know how to handle pointers.

Well, here is one difference. An object pointer (dereferencable )
needs to point to memory, since that is where the value of the
object is stored. However a function pointer needs to load AND
EXECUTE code. That may well be stored in a shared library, and the
reference is to a location in a file. This is one reason function
pointers and object pointers are not interchangeable ; the function
pointer may need much more data.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Tristan Miller]

Re: Good Tutorials

Greetings.

In article
<3f8adc51-f9af-4da2-8580-0be40f99615d@s9 g2000prg.google groups.com>,
Amkcoder wrote:

Every time you declare a pointer space is allocated for it to hold a
value

Oh, really? Perhaps you could explain to us, then, how and where the
system allocates space for the following pointer declaration?

extern int *p;

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= < In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you