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

[pauldepstein]

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

 

[Alf P. Steinbach]

* (e-mail address removed):

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

 

[pauldepstein]

* (e-mail address removed):













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.



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.




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

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

 

[James Kanze]

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.