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

Discussion in 'C++' started by Robert Macy, Oct 27, 2005.

  1. Robert Macy

    Robert Macy Guest

    I got all the way through the first section!

    I especially like your comment about reading the code from right to
    left. I've been doing that technique with much of the help from the MS
    website, not on a line basis, but on a conceptual basis. Right to
    left? then it dawned on me that math is right to left. As in, C equals
    A plus B etc. As opposed to A plus B equals C. Then I remembered, that
    our math [numbers] came from Arabic origins which is also right to
    left. All making more sense now.

    However, I am stuck at one concept. On page 13 [page 15 of pdf] there
    is a section of code that varies from ok to "not ok" at the last line.
    I tried compiling the code into a simple program, test.cpp. On MSVC
    line command on the XP, the compiler first would not accept a constant
    *unless* the constant is initialized to some value. Nice check. And
    sure enough, as you predicted, the compiler would not process the line
    16

    /* from page 15
    */
    #include <iostream> // std::cout
    #include <ostream> // std::endl

    int main()
    {
    int o;
    int const oConst = 1; // must initialize a constant
    int* p = &o;
    int const* pConst = &oConst;

    pConst = p; // ok
    pConst = pConst; // ok
    p = p; // ok
    p = pConst; // won't compile ??
    }
    /*
    Line 16 prevents this from compiling
    test.cpp(16) : error C2440: '=' : cannot convert from 'const int *' to
    'int *'
    Conversion loses qualifiers
    */

    For me, it looked like pConst=p; should cause a problem. I must be
    missing what the equals sign means here.

    - Robert -
     
    Robert Macy, Oct 27, 2005
    #1
    1. Advertising

  2. Robert Macy

    Marcus Kwok Guest

    Robert Macy <> wrote:
    > However, I am stuck at one concept. On page 13 [page 15 of pdf] there
    > is a section of code that varies from ok to "not ok" at the last line.
    > I tried compiling the code into a simple program, test.cpp. On MSVC
    > line command on the XP, the compiler first would not accept a constant
    > *unless* the constant is initialized to some value. Nice check. And
    > sure enough, as you predicted, the compiler would not process the line
    > 16
    >
    > int o;
    > int const oConst = 1; // must initialize a constant
    > int* p = &o;
    > int const* pConst = &oConst;

    [snip]
    > p = pConst; // won't compile ??


    > test.cpp(16) : error C2440: '=' : cannot convert from 'const int *' to
    > 'int *'
    > Conversion loses qualifiers


    > For me, it looked like pConst=p; should cause a problem. I must be
    > missing what the equals sign means here.


    When you try to assign "regular pointer = pointer to const", then that
    implies that pointer should be allowed to change the object pointed to.
    Trying to change a const object is very bad, so it was decided to
    prevent that at compile time.


    --
    Marcus Kwok
     
    Marcus Kwok, Oct 27, 2005
    #2
    1. Advertising

  3. Robert Macy

    BobR Guest

    Robert Macy wrote in message
    >
    >However, I am stuck at one concept. On page 13 [page 15 of pdf] there
    >is a section of code that varies from ok to "not ok" at the last line.
    >I tried compiling the code into a simple program, test.cpp. On MSVC
    >line command on the XP, the compiler first would not accept a constant
    >*unless* the constant is initialized to some value. Nice check. And
    >sure enough, as you predicted, the compiler would not process the line
    >16
    >
    >/* from page 15
    >*/
    >#include <iostream> // std::cout
    >#include <ostream> // std::endl
    >
    >int main()
    >{
    > int o;
    > int const oConst = 1; // must initialize a constant
    > int* p = &o;
    > int const* pConst = &oConst;
    >
    > pConst = p; // ok
    > pConst = pConst; // ok
    > p = p; // ok
    > p = pConst; // won't compile ??
    >}
    >/*
    >Line 16 prevents this from compiling
    >test.cpp(16) : error C2440: '=' : cannot convert from 'const int *' to
    >'int *'
    > Conversion loses qualifiers
    >*/
    >
    >For me, it looked like pConst=p; should cause a problem. I must be
    >missing what the equals sign means here.
    >
    > - Robert -


    // p is pointing to memory that can be *read* or written to (RW).
    *p = 43; // should be no problem.

    pConst = p; // should not cause a problem. The 'int' *can* be read.
    // *pConst = 43; // should cause a problem. "assignment of read-only
    location"
    // The 'int' is constant (RO), not the pointer to it.

    int * const pcConst = &o;
    // pcConst = p; // should cause a problem. The pointer is const.
    // "assignment of read-only variable `pcConst' "
    *pcConst = 43; // should not cause a problem. What it points to is RW.

    int const * const pccConst = &oConst;
    // pccConst = p; // nope. The pointer is const.
    // *pccConst = 43; // nope. What it points to is RO.

    --
    Bob R
    POVrookie
     
    BobR, Oct 27, 2005
    #3
  4. * Robert Macy:
    >
    > However, I am stuck at one concept. On page 13 [page 15 of pdf] there
    > is a section of code that varies from ok to "not ok" at the last line.
    > I tried compiling the code into a simple program, test.cpp. On MSVC
    > line command on the XP, the compiler first would not accept a constant
    > *unless* the constant is initialized to some value. Nice check.


    Thanks, will fix.


    > ...
    > For me, it looked like pConst=p; should cause a problem. I must be
    > missing what the equals sign means here.


    The equals sign is just an ordinary assignment.

    The assignment is accepted because you can't do any "harm" via the
    pConst pointer.

    But you're right that there _is_ a problem, namely that with the pConst
    pointer in hand one might be expecting that it points to an unchanging
    object. Then someone uses the p pointer that it came from, to change
    that object, and whoops. The problem here is not the changing object,
    but the expectation of an unchanging object.

    A pointer to const does _not_ guarantee an unchanging object.

    What it guarantees (except for using low-level features to circumvent
    the rules) is that the object can't be changed via _that_ pointer, that
    some code that only has _that_ pointer in hand, can't change the pointed
    to object.

    This should perhaps be discussed in greater detail.

    I just said, look at it, then look at it again, until it's "obvious"...
    ;-)

    --
    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
    #4
  5. Robert Macy

    Robert Macy Guest

    I'm still staring at it ! ! ! :)

    But, BobR's comments are making me start to think in terms of RO memory
    and assignments rather than constants and equals. That is thinning the
    fog a bit.

    - Robert -
     
    Robert Macy, Oct 27, 2005
    #5
  6. * Robert Macy:
    > I'm still staring at it ! ! ! :)
    >
    > But, BobR's comments are making me start to think in terms of RO memory
    > and assignments rather than constants and equals. That is thinning the
    > fog a bit.


    Evidently, _much_ more detailed discussion than I provided is required.

    Something like BobR's comments, on the basic meaning of 'const'.

    Consider this:

    int* p;

    p = 0; // OK.
    *p = 0; // OK when p points to some actual variable.

    p is not constant. Read backwards: p is a pointer to a read/write int.
    p can be assigned to. *p, the int, can be assigned to.

    Since *p can be assigned to, you're not allowed to initialize p to point
    to a constant int, or to later point it towards a constant int, because
    then you could assign to that constant variable via *p = somevalue.

    Next:

    int const* p;

    p = 0; // OK.
    *p = 0; // !Not permitted.

    p is not constant. Read backwards: p is a pointer to a constant, a
    read-only, int. p can be assigned to. *p, the int, can only be read.

    Since *p can only be read, p can be pointed to any int variable, because
    all int variables support reading their contents.

    Third:

    int* const p = &o;

    p = 0; // !Not permitted.
    *p = 0; // OK when p points to some actual variable.

    p is constant. Read backwards: p is a constant, a read-only pointer to
    a read/write int. p can not be assigned to. *p, the int, can be
    assigned to.

    Since *p can be assigned to, you're not allowed to initialize p to point
    to a constant int, because then you could assign to that variable via *p
    = somevalue.

    Finally:

    int const* const p = &o;

    p = 0; // !Not permitted.
    *p = 0; // !Not permitted.

    p is constant. Read backwards: p is a constant, a read-only pointer to
    a constant, a read-only int. p can only be read. *p, the int, can only
    be read.

    Since *p can only be read, p can be pointed to any int variable, because
    all int variables support reading their contents.

    --
    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
    #6
  7. Robert Macy

    Robert Macy Guest

    That's good.

    Whew, now I can move on. :)

    - Robert -
     
    Robert Macy, Oct 27, 2005
    #7
    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.
Similar Threads
  1. Robert Macy
    Replies:
    11
    Views:
    529
    Greg Comeau
    Nov 5, 2005
  2. Chris ( Val )
    Replies:
    11
    Views:
    484
    Greg Comeau
    Nov 5, 2005
  3. Alf P. Steinbach
    Replies:
    4
    Views:
    535
    Alf P. Steinbach
    Nov 28, 2005
  4. James Dennett
    Replies:
    15
    Views:
    527
    Marcus Kwok
    Nov 15, 2005
  5. Whispering Voice
    Replies:
    0
    Views:
    243
    Whispering Voice
    Nov 14, 2012
Loading...

Share This Page