Smart pointers in C++ Primer -- possible const inconsistency

Discussion in 'C++' started by pauldepstein@att.net, May 17, 2009.

  1. Guest

    My text is the 4th ed. of C++ Primer by Lippman, Lajoie and Moo. I
    have a question about the following smart pointer code from this text:

    class U_Ptr
    {friend class HasPtr;
    int* ip;
    size_t use;
    U_Ptr(int* p): ip(p), use(1) {}
    ~U_Ptr() { delete ip;}
    };

    class HasPtr{
    public:
    void set_ptr(int* p) {ptr -> ip = p;} // THIS IS A NON_CONST METHOD

    private:
    U_Ptr* ptr;

    // Public and private methods and members continue

    };


    Later in the text, a different implentation of HasPtr is given:

    class HasPtr{
    public:
    HasPtr(const int& p, int i): ptr(new int(p)), val(i) {}

    private:
    int* ptr;
    int val;

    public:
    void set_ptr_val(int p) const { *ptr = p; } //CONST METHOD

    // Public and private methods and members continue
    };


    As I see it set_ptr and set_ptr_val don't change their class members
    and can both legally be labelled const.

    Some might choose to make the pointer-setting methods non-const
    according to the logic that data is being changed through the pointer
    so the set_ptr methods might be said to be conceptually non-const.

    It seems very strange to me to make one of the pointer-setting methods
    non-const and the other pointer-setting method const.

    This has not been commented on in the online errata list.

    Am I missing something?

    Is there any reason why set_ptr needs to be non-const?

    Many thanks for your help.

    Paul Epstein
     
    , May 17, 2009
    #1
    1. Advertising

  2. * :
    > My text is the 4th ed. of C++ Primer by Lippman, Lajoie and Moo. I
    > have a question about the following smart pointer code from this text:
    >
    > class U_Ptr
    > {friend class HasPtr;
    > int* ip;
    > size_t use;
    > U_Ptr(int* p): ip(p), use(1) {}
    > ~U_Ptr() { delete ip;}
    > };
    >
    > class HasPtr{
    > public:
    > void set_ptr(int* p) {ptr -> ip = p;} // THIS IS A NON_CONST METHOD
    >
    > private:
    > U_Ptr* ptr;
    >
    > // Public and private methods and members continue
    >
    > };
    >
    >
    > Later in the text, a different implentation of HasPtr is given:
    >
    > class HasPtr{
    > public:
    > HasPtr(const int& p, int i): ptr(new int(p)), val(i) {}
    >
    > private:
    > int* ptr;
    > int val;
    >
    > public:
    > void set_ptr_val(int p) const { *ptr = p; } //CONST METHOD
    >
    > // Public and private methods and members continue
    > };
    >
    >
    > As I see it set_ptr and set_ptr_val don't change their class members
    > and can both legally be labelled const.


    It has to do with logical constness, that a method that changes the logical
    state of the object as viewed from client code, should not be 'const' (and vice
    versa). Which is tricky for smart pointers and depends on the smart pointer's
    const convention. But that trickiness doesn't matter because the code is bad.


    > Some might choose to make the pointer-setting methods non-const
    > according to the logic that data is being changed through the pointer
    > so the set_ptr methods might be said to be conceptually non-const.
    >
    > It seems very strange to me to make one of the pointer-setting methods
    > non-const and the other pointer-setting method const.


    Yes, but the code shown is not an example to follow in any respect.

    Presumably it's just the minimal code to illustrate some technical point, in
    which case the explanation might reside in the context in the book.


    > This has not been commented on in the online errata list.
    >
    > Am I missing something?
    >
    > Is there any reason why set_ptr needs to be non-const?


    It needs to be non-const for the purpose of preserving logical constness.

    And possibly, but that's a very tentative conclusion based on very sketchy
    evidence, just this posting and a recent other posting about the same book, but
    possibly you'd be better served by switching to some other textbook.



    Cheers & hth.,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, May 17, 2009
    #2
    1. Advertising

  3. Guest

    On May 17, 12:23 pm, "Alf P. Steinbach" <> wrote:
    > * :
    >
    >
    >
    > > My text is the 4th ed. of C++ Primer by Lippman, Lajoie and Moo.  I
    > > have a question about the following smart pointer code from this text:

    >
    > > class U_Ptr
    > > {friend class HasPtr;
    > > int* ip;
    > > size_t use;
    > > U_Ptr(int* p): ip(p), use(1) {}
    > > ~U_Ptr() { delete ip;}
    > > };

    >
    > > class HasPtr{
    > > public:
    > > void set_ptr(int* p) {ptr -> ip = p;} // THIS IS A NON_CONST METHOD

    >
    > > private:
    > > U_Ptr* ptr;

    >
    > > // Public and private methods and members continue

    >
    > > };

    >
    > > Later in the text, a different implentation of HasPtr is given:

    >
    > > class HasPtr{
    > > public:
    > > HasPtr(const int& p, int i): ptr(new int(p)), val(i) {}

    >
    > > private:
    > > int* ptr;
    > > int val;

    >
    > > public:
    > > void set_ptr_val(int p) const { *ptr = p; } //CONST METHOD

    >
    > > // Public and private methods and members continue
    > > };

    >
    > > As I see it set_ptr and set_ptr_val don't change their class members
    > > and can both legally be labelled const.

    >
    > It has to do with logical constness, that a method that changes the logical
    > state of the object as viewed from client code, should not be 'const' (and vice
    > versa). Which is tricky for smart pointers and depends on the smart pointer's
    > const convention. But that trickiness doesn't matter because the code is bad.
    >
    > > Some might choose to make the pointer-setting methods non-const
    > > according to the logic that data is being changed through the pointer
    > > so the set_ptr methods might be said to be conceptually non-const.

    >
    > > It seems very strange to me to make one of the pointer-setting methods
    > > non-const and the other pointer-setting method const.

    >
    > Yes, but the code shown is not an example to follow in any respect.
    >
    > Presumably it's just the minimal code to illustrate some technical point, in
    > which case the explanation might reside in the context in the book.
    >
    > > This has not been commented on in the online errata list.

    >
    > > Am I missing something?

    >
    > > Is there any reason why set_ptr needs to be non-const?

    >
    > It needs to be non-const for the purpose of preserving logical constness.
    >
    > And possibly, but that's a very tentative conclusion based on very sketchy
    > evidence, just this posting and a recent other posting about the same book, but
    > possibly you'd be better served by switching to some other textbook.
    >
    > Cheers & hth.,
    >
    > - Alf
    >
    > --
    > Due to hosting requirements I need visits to <url:http://alfps.izfree.com/>.
    > No ads, and there is some C++ stuff! :) Just going there is good. Linking
    > to it is even better! Thanks in advance!


    Thanks Alf,

    A few questions remain:
    1) Why is the code bad? I should note that the text does group public
    and private methods together in the conventional way. For ease of
    writing, I singled out the methods and defs I wanted to talk about and
    thereby changed the ordering (but not the content) of the access
    labels.

    2) In the 2nd implementation of HasPtr, there is this code:

    class HasPtr{
    public:
    HasPtr(const int& p, int i): ptr(new int(p)), val(i) {}

    private:
    int* ptr;
    int val;

    public:
    void set_ptr_val(int p) const { *ptr = p; } //CONST METHOD
    //Public and private methods and members continue
    };

    Doesn't the const method above violate logical constness? If not, why
    not? It is the constness of set_ptr_val as above that motivated my
    original posting.

    3) Which other textbook(s) do you recommend? I know that there are
    tons of suggestions on the web, but since you brought up the subject
    of a textbook switch, I'd like to ask you your suggestion.

    I think the content and general approach of C++ Primer is excellent.
    The problem is that it has tons of errors but the online errata help
    with that.

    4) Which "recent posting" are you referring to?

    Thanks again.

    Paul Epstein
     
    , May 17, 2009
    #3
  4. James Kanze Guest

    On May 17, 1:14 pm, wrote:
    > On May 17, 12:23 pm, "Alf P. Steinbach" <> wrote:
    > > * :


    > A few questions remain:
    > 2) In the 2nd implementation of HasPtr, there is this code:


    > class HasPtr{
    > public:
    > HasPtr(const int& p, int i): ptr(new int(p)), val(i) {}


    > private:
    > int* ptr;
    > int val;


    > public:
    > void set_ptr_val(int p) const { *ptr = p; } //CONST METHOD
    > //Public and private methods and members continue
    > };


    > Doesn't the const method above violate logical constness? If
    > not, why not? It is the constness of set_ptr_val as above
    > that motivated my original posting.


    What is the abstraction of HasPtr? Without knowing that, it's
    really impossible to say what logical const means. But if the
    abstraction is that of a pointer, then something that changes
    the value of what is pointed doesn't logically change the value
    of the object itself.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 17, 2009
    #4
    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. MotoK
    Replies:
    59
    Views:
    1,867
    Keith Thompson
    Sep 15, 2006
  2. coala
    Replies:
    3
    Views:
    400
    coala
    Sep 6, 2006
  3. Replies:
    1
    Views:
    319
    Andrew Koenig
    May 3, 2007
  4. Javier
    Replies:
    2
    Views:
    606
    James Kanze
    Sep 4, 2007
  5. CplusplusNewbie
    Replies:
    17
    Views:
    1,837
Loading...

Share This Page