468,720 Members | 1,695 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,720 developers. It's quick & easy.

boost::shared_ptr and operator->()

Something puzzles me about Boost's shared_ptr implementation:

template <typename T>
class shared_ptr
{
public:
T* operator->() const
{
return p;
}
private:
T* p;
};

Why is operator->() const but the return value is non-const? The
Boost documentation answers this very question as follows:

"Shallow copy pointers, including raw pointers, typically don't
propagate constness. It makes little sense for them to do so, as you
can always obtain a non-const pointer from a const one and then
proceed to modify the object through it."

I don't understand this answer. Are they referring to using
const_cast to subvert the constness of shallow copy pointers? If so,
that seems like a weak argument for not enforcing const corectness.

Any insights appreciated.
Jul 22 '05 #1
2 1424
Derek wrote in news:br*************@ID-46268.news.uni-berlin.de:
Something puzzles me about Boost's shared_ptr implementation:

template <typename T>
class shared_ptr
{
public:
T* operator->() const
{
return p;
}
private:
T* p;
};

Why is operator->() const but the return value is non-const? The
Boost documentation answers this very question as follows:

"Shallow copy pointers, including raw pointers, typically don't
propagate constness. It makes little sense for them to do so, as you
can always obtain a non-const pointer from a const one and then
proceed to modify the object through it."

Perhapse this will help (for illustration only), what a shared_ptr would
"look" like when const:

template <typename T>
class shared_ptr_const
{
public:
T* const operator->()
{
return p;
}
private:
T* const p;
};

Note that its T * const p *not* T const *p;

T t;
T *v;
T * const c = &t;
v = c; /* shallow copy ?? (losses toplevel const)*/

The (legal) copy above is the same (in a const-correct sense) as:

int const ic = 2;
int j = ic;

Adding (toplevel) const to a return type (as I did in the
illustration above) is mostly useless.
I don't understand this answer. Are they referring to using
const_cast to subvert the constness of shallow copy pointers? If so,
that seems like a weak argument for not enforcing const corectness.


Nope, that's not what is being discussed.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #2
Rob, your reply makes perfect sense. I overlooked that a const
shared_ptr's member raw pointer is T* const p, not T const *p. Thanks.
Derek wrote in
news:br*************@ID-46268.news.uni-berlin.de:
Something puzzles me about Boost's shared_ptr
implementation:

template <typename T>
class shared_ptr
{
public:
T* operator->() const
{
return p;
}
private:
T* p;
};

Why is operator->() const but the return value
is non-const? The Boost documentation answers
this very question as follows:

"Shallow copy pointers, including raw pointers,
typically don't propagate constness. It makes
little sense for them to do so, as you can always
obtain a non-const pointer from a const one and
then proceed to modify the object through it."


Perhapse this will help (for illustration only), what a
shared_ptr would "look" like when const:

template <typename T>
class shared_ptr_const
{
public:
T* const operator->()
{
return p;
}
private:
T* const p;
};

Note that its T * const p *not* T const *p;

T t;
T *v;
T * const c = &t;
v = c; /* shallow copy ?? (losses toplevel const)*/

The (legal) copy above is the same (in a const-correct
sense) as:

int const ic = 2;
int j = ic;

Adding (toplevel) const to a return type (as I did in the
illustration above) is mostly useless.
I don't understand this answer. Are they referring to
using const_cast to subvert the constness of shallow
copy pointers? If so, that seems like a weak argument
for not enforcing const corectness.


Nope, that's not what is being discussed.

Rob. -- http://www.victim-prime.dsl.pipex.com/

Jul 22 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by ctick | last post: by
6 posts views Thread by Ryan Mitchley | last post: by
2 posts views Thread by krema2ren | last post: by
2 posts views Thread by adebaene | last post: by
5 posts views Thread by Jun | last post: by
9 posts views Thread by Christopher | last post: by
4 posts views Thread by EnsGabe | last post: by
1 post views Thread by CARIGAR | last post: by
1 post views Thread by Oskars | last post: by
9 posts views Thread by bryonone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.