«

Alf P. Steinbach wrote:
> So, I got the itch to write something more...
>
> I apologize for not doing more on the attempted "Correct C++ Tutorial"
> earlier, but there were reasons.
>
> This is an UNFINISHED and RAW document, and at the end there is even pure
> mindstorming text left in, but already I think it can be very useful.
>
> <url: http://home.no.net/dubjai/win32cpptut/special/pointers/preview/pointers_01__alpha.doc.pdf>.
>
>
> What do you think?
>
> In particular, if you find any grave errors, please do not hesitate to
> comment. I always make errors. Those I agree are errors will be corrected.

Hi Alf,

I am very busy at the moment, but I had a very, very brief look,
and a few things caught my eye, and that was to do with wording.

I will look at the rest when I get a chance.
Btw, it's just an opinion, so don't get too heated over it

1 Pointers:
A pointer is a value that identifies where some object or
function is located in the computer's memory.

// I would have said something along the lines of:
* A pointer is a special type of variable that stores an address.

* The address stored in the pointer is an integral value, which
points to a location in the computer's memory.

* Just like an address that identifies where a house is located
on your street, the pointer address in turn identifies exactly
where in memory an object of a given type can be located.


1.1 Introduction to the basics.

// Remove this line or re-phrase it (covered in the text above):
A pointer that tells where an object o is located is said to point to
o.

// A few lines down we find:
*p = 42; Assigning to the object a pointer points to.
which doesn't change p, but the object that p points to.

That's called dereferencing. (*)

I think this (*) is a little misleading - Although the operation
is called assignment, it is not clear what you are actually calling
dereferencing. Even though you mention the dereferencing operator
a few more lines down, it has not been made clear what the act of
dereferencing actually means.

AFAIU, dereferencing is the act of applying an operator to a pointer
variable, to ultimately access the undelying value of the object being
pointed to - I think this or similar explanation should be provided
for the newbie.

// <nit> In the following sentence you have:
And to make p point to o you just apply the address operator, &, to o:

In this particular context, I always new this operator to be called
the "address of" operator, rather than just the "address operator".

// For your question in the following, I would add (shown below):
p = &o; // Set p to point to o.
*p = 42; // Assign
And, for example, does the order of the two commented statements
matter?

* Yes, it does matter, and that is where one advantage of
initialisation can help, if appropriate:

int* p( &o ); // no order to worry about

Sorry I could not look at more of your tutorial (for now), but I
will when I get some more time.

Hope my opinions were useful

Cheers,
Chris Val

* Chris ( Val ):
> * Alf P. Steinbach:
> >
> > <url: http://home.no.net/dubjai/win32cpptut/special/pointers/preview/pointers_01__alpha.doc.pdf>.
> >
> > What do you think?
>
> I am very busy at the moment, but I had a very, very brief look,
> and a few things caught my eye, and that was to do with wording.
>
> I will look at the rest when I get a chance.
> Btw, it's just an opinion, so don't get too heated over it
>
> 1 Pointers:
> A pointer is a value that identifies where some object or
> function is located in the computer's memory.
>
> // I would have said something along the lines of:
> * A pointer is a special type of variable that stores an address.
>
> * The address stored in the pointer is an integral value, which
> points to a location in the computer's memory.
>
> * Just like an address that identifies where a house is located
> on your street, the pointer address in turn identifies exactly
> where in memory an object of a given type can be located.

Well, I basically like your idea of pointing out (!) that a pointer is
effectively integral: you can increment and decrement pointers, and
there are no pointer values in between the values so generated (although
for some pointers these operations give undefined behavior).

There are however two reasons why I think it would not be a good idea to
mention that. First and foremost, the standard reserves the term
"integral type" to mean bool, char, wchar_t, and the signed and unsigned
integer types (the term integral type is defined in paragraph 3.9.1/7),
i.e.,

a pointer type is _not_ integral

in the standard's definition of the term. Second reason, I'd rather not
get into a discussion of raw arrays at this point, both because there's
so much said about that topic, and because the beginner is much better
served by using e.g. std::vector and std::string instead.

Regarding "special" and "variable": nope, a pointer is neither special
nor necessarily a variable. We often say that e.g. a function returns a
pointer to such and such. The function does not return a variable.

Regarding "an object": nope, a pointer does not necessarily point to an
object.

Actually I took pains to explain that last in detail, most of the ways
that a valid C++ pointer need _not_ point to an object. But then I
goofed on the introductory sentence! So thanks also for focusing on
that sentence. But how should it be rephrased? Perhaps put in the word
"basically" or some such, in parenthesis?


> 1.1 Introduction to the basics.
>
> // Remove this line or re-phrase it (covered in the text above):
> A pointer that tells where an object o is located is said to point to
> o.

It defines the term "point to" (shown in bold green), not yet covered.


> // A few lines down we find:
> *p = 42; Assigning to the object a pointer points to.
> which doesn't change p, but the object that p points to.
>
> That's called dereferencing. (*)
>
> I think this (*) is a little misleading - Although the operation
> is called assignment, it is not clear what you are actually calling
> dereferencing. Even though you mention the dereferencing operator
> a few more lines down, it has not been made clear what the act of
> dereferencing actually means.

Thanks -- perhaps just replace "that" by "applying *"?


> AFAIU, dereferencing is the act of applying an operator to a pointer
> variable, to ultimately access the undelying value of the object being
> pointed to - I think this or similar explanation should be provided
> for the newbie.
>
> // <nit> In the following sentence you have:
> And to make p point to o you just apply the address operator, &, to o:
>
> In this particular context, I always new this operator to be called
> the "address of" operator, rather than just the "address operator".

Not sure.


> // For your question in the following, I would add (shown below):
> p = &o; // Set p to point to o.
> *p = 42; // Assign
> And, for example, does the order of the two commented statements
> matter?
>
> * Yes, it does matter, and that is where one advantage of
> initialisation can help, if appropriate:
>
> int* p( &o ); // no order to worry about

Here I think I'll leave it as-is. In order to present a clean example I
deliberately did not use initialization. The example as-is shows that a
pointer variable isn't necessarily initialized at the point of
declaration. Bringing in C++ direct initializer syntax would just
confuse things, I think. Better with a minimal, clean example.

I hold to that guideline throughout the tutorial and this document.

For example, from a "best possible C++" view most of the classes I
present would benefit greatly from using constructors, access specifiers
and so on. But that would not help get across the points I want to get
across, it would just add more extranous things to deal with for the
reader (who possibly hasn't yet been introduced to those features, and
anyway does not necessarily see what their usage is all about in any
particular example). Instead I've chosen to present the minimum number
of concepts at a time, with minimum extranous clutter.


> Sorry I could not look at more of your tutorial (for now), but I
> will when I get some more time.
>
> Hope my opinions were useful

Yes, they were. Thank you,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
> Regarding "special" and "variable": nope, a pointer is neither special
> nor necessarily a variable. We often say that e.g. a function
> returns a pointer to such and such. The function does not return a
> variable.

Actually, a function like the one you describe here doesn't return a
pointer. It returns a pointer *value*, which in this case is a constant
with a very short life expectancy (i.e. if you don't use it right away, it's
gone).


--

Sigurd
http://utvikling.com

Chris ( Val ) wrote:
> * The address stored in the pointer is an integral value, which
> points to a location in the computer's memory.

You imply a linear address space, and that is not necessarily correct.

Also, arithmetics are different for pointers than for integral types. For
instance, if you add 1 to a pointer the internal representation may increase
by any amount (depending on the size of what's pointed to).


--

Sigurd
http://utvikling.com

* Sigurd Stenersen:
> Alf P. Steinbach wrote:
> > Regarding "special" and "variable": nope, a pointer is neither special
> > nor necessarily a variable. We often say that e.g. a function
> > returns a pointer to such and such. The function does not return a
> > variable.
>
> Actually, a function like the one you describe here doesn't return a
> pointer. It returns a pointer *value*, which in this case is a constant
> with a very short life expectancy (i.e. if you don't use it right away, it's
> gone).

Actually, it returns a pointer.

Depending on the context, the word "pointer" can mean

* A pointer value.

* A pointer variable.

* A pointer type.

The last usage is not very common in ordinary programming, but abounds
in the standard.

And the list above is not exhaustive. For example, we differentiate
between "raw pointers" and "smart pointers". Where "pointer" denotes a
more general _concept_, and is restricted to a specialization of that
concept by prepending a qualification.

So, it would be wrong, terminologically, to define pointer as
"variable".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
> * Sigurd Stenersen:
>> Alf P. Steinbach wrote:
>>> Regarding "special" and "variable": nope, a pointer is neither
>>> special nor necessarily a variable. We often say that e.g. a
>>> function returns a pointer to such and such. The function does not
>>> return a variable.
>>
>> Actually, a function like the one you describe here doesn't return a
>> pointer. It returns a pointer *value*, which in this case is a
>> constant with a very short life expectancy (i.e. if you don't use it
>> right away, it's gone).
>
> Actually, it returns a pointer.

Actually, that's sloppy language. The fact that a lot of people use sloppy
language does *not* mean it's correct.


> Depending on the context, the word "pointer" can mean
>
> * A pointer value.

In the given context, that is exactly what it means.


--

Sigurd
http://utvikling.com

Sigurd Stenersen wrote:

> Alf P. Steinbach wrote:
>> * Sigurd Stenersen:
>>> Alf P. Steinbach wrote:
>>>> Regarding "special" and "variable": nope, a pointer is neither
>>>> special nor necessarily a variable. We often say that e.g. a
>>>> function returns a pointer to such and such. The function does not
>>>> return a variable.
>>>
>>> Actually, a function like the one you describe here doesn't return a
>>> pointer. It returns a pointer *value*, which in this case is a
>>> constant with a very short life expectancy (i.e. if you don't use it
>>> right away, it's gone).
>>
>> Actually, it returns a pointer.
>
> Actually, that's sloppy language. The fact that a lot of people use
> sloppy language does *not* mean it's correct.
>
>
>> Depending on the context, the word "pointer" can mean
>>
>> * A pointer value.
>
> In the given context, that is exactly what it means.

It is not sloppy language. The use by many people is, indeed immaterial, but
the use within the standard is not. The standard clearly blesses this use
of the word "pointer". That is what makes it correct (in this context).


Best

Kai-Uwe Bux

* Sigurd Stenersen:
> Alf P. Steinbach wrote:
> > * Sigurd Stenersen:
> >> Alf P. Steinbach wrote:
> >>> Regarding "special" and "variable": nope, a pointer is neither
> >>> special nor necessarily a variable. We often say that e.g. a
> >>> function returns a pointer to such and such. The function does not
> >>> return a variable.
> >>
> >> Actually, a function like the one you describe here doesn't return a
> >> pointer. It returns a pointer *value*, which in this case is a
> >> constant with a very short life expectancy (i.e. if you don't use it
> >> right away, it's gone).
> >
> > Actually, it returns a pointer.
>
> Actually, that's sloppy language. The fact that a lot of people use sloppy
> language does *not* mean it's correct.
>
>
> > Depending on the context, the word "pointer" can mean
> >
> > * A pointer value.
>
> In the given context, that is exactly what it means.

Well, then by your own definition it's neither incorrect nor sloppy
language.

As I see it, the pointer value meaning is the basic meaning of pointer,
from which other meanings derive.

As you see it, the basic meaning is a pointer variable (I think you mean
"object", because in the standard's definition a variable needs a name).

As the authors of the Wikipedia article on pointers see it, the basic
meaning is a data type, "a pointer is a programming language data type".

Can we agree at least that "pointer" does have a broader meaning than
just "pointer variable", that it's _not_ incorrect or sloppy language to
say that a function returns a pointer?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
> Can we agree at least that "pointer" does have a broader meaning than
> just "pointer variable", that it's _not_ incorrect or sloppy language
> to say that a function returns a pointer?

Yes, I agree. The reason that this is correct is that functions can return
nothing but values, so it's given that a returned pointer is in fact a
pointer value.

BTW I was not the one claiming that "pointer" means "variable".


--

Sigurd
http://utvikling.com

Sigurd Stenersen wrote:

> Alf P. Steinbach wrote:
>
>>* Sigurd Stenersen:
>>
>>>Alf P. Steinbach wrote:
>>>
>>>>Regarding "special" and "variable": nope, a pointer is neither
>>>>special nor necessarily a variable. We often say that e.g. a
>>>>function returns a pointer to such and such. The function does not
>>>>return a variable.
>>>
>>>Actually, a function like the one you describe here doesn't return a
>>>pointer. It returns a pointer *value*, which in this case is a
>>>constant with a very short life expectancy (i.e. if you don't use it
>>>right away, it's gone).
>>
>>Actually, it returns a pointer.
>
>
> Actually, that's sloppy language. The fact that a lot of people use sloppy
> language does *not* mean it's correct.

The fact that one group of people uses one particular formal
definition of a term does not mean that that definition is the
most correct, or that other definitions are incorrect.

It does mean that we're best to remember that definitions are
not universal, and be clear where necessary what we mean when
we use an overloaded term.

-- James