Re: Pointers and polymorphism explained [preview, PDF, part of my attempted "Correct C++ Tutorial"]

Discussion in 'C++' started by Chris ( Val ), Oct 27, 2005.

  1. 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 ), Oct 27, 2005
    #1
    1. Advertising

  2. * 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, Oct 27, 2005
    #2
    1. Advertising

  3. 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
     
    Sigurd Stenersen, Oct 27, 2005
    #3
  4. 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, Oct 27, 2005
    #4
  5. * 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, Oct 27, 2005
    #5
  6. 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, Oct 27, 2005
    #6
  7. Chris ( Val )

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Oct 27, 2005
    #7
  8. * 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, Oct 27, 2005
    #8
  9. 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, Oct 27, 2005
    #9
  10. Re: Pointers and polymorphism explained [preview, PDF, part of myattempted "Correct C++ Tutorial"]

    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
     
    James Dennett, Oct 29, 2005
    #10
  11. Chris ( Val )

    Greg Comeau Guest

    In article <>,
    Sigurd Stenersen <> wrote:
    >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).


    Yep. Pointer is one of those words we like to toss about, generically,
    but when you get into the language itself, it does end up needing to
    be qualified.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Nov 5, 2005
    #11
  12. Chris ( Val )

    Greg Comeau Guest

    In article <>,
    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.
    >
    >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".


    Yes, it would be formally incorrect, if it were only defined as such.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Nov 5, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page