Interest in a protected pointer

Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well. For example: template<typename T> class protected_ptr { T * ptr; // ... T * get(); const T * get() const; // ... including operator* and operator-> } class Foo { protected_ptr<Bar> _bar; void Func1() { _bar->NonConstFunc(); _bar->ConstFunc(); } void Func2() const { _bar->NonConstFunc(); // Compile error _bar->ConstFunc(); // Ok } } Ray Logel

on Tue Feb 10 2009, Ray Logel <rlogel-AT-navtechinc.com> wrote:
Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well.
Have you tried shared_ptr<T const> ? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

AMDG David Abrahams wrote:
on Tue Feb 10 2009, Ray Logel <rlogel-AT-navtechinc.com> wrote:
Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well.
Have you tried shared_ptr<T const> ?
I think the idea is to propagate pointer constness to the pointee. dereferencing shared_ptr<T const> always gives const T& In Christ, Steven Watanabe

Is there a way to specialize the std::tr1::hash functor that works the same for the boost implementation and the native MSVC 2008 and GCC 4.3 implementations? It appears that the Boost hash_value free function approach is not supported by the MSVC 2008 implementation, and specialization of the hash functor template has to occur in the original namespace of hash, regardless of any using declarations. Currently I'm using the macro BOOST_HAS_TR1_HASH to decide if I'm using a "native" TR1 implementation or the boost-provided one, and putting it in namespace boost vs. namespace std::tr1 based on the decision. This isn't really a problem, I was just wondering if I had missed an easier way. Thanks, Gregory Peele, Jr. Applied Research Associates Inc.

Is there a way to specialize the std::tr1::hash functor that works the same for the boost implementation and the native MSVC 2008 and GCC 4.3 implementations? It appears that the Boost hash_value free function approach is not supported by the MSVC 2008 implementation, and specialization of the hash functor template has to occur in the original namespace of hash, regardless of any using declarations.
Currently I'm using the macro BOOST_HAS_TR1_HASH to decide if I'm using a "native" TR1 implementation or the boost-provided one, and putting it in namespace boost vs. namespace std::tr1 based on the decision. This isn't really a problem, I was just wondering if I had missed an easier way.
Unfortunately I believe that's the only way, John,

Ray Logel wrote:
Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well.
For example: template<typename T> class protected_ptr { T * ptr;
// ... T * get(); const T * get() const;
// ... including operator* and operator-> }
class Foo { protected_ptr<Bar> _bar;
void Func1() { _bar->NonConstFunc(); _bar->ConstFunc(); }
void Func2() const { _bar->NonConstFunc(); // Compile error _bar->ConstFunc(); // Ok } }
Ray Logel
The could be useful to propagate constness, however it looks like the boost smart pointers deliberately dont do that. The following is an excerpt from shared_ptr's faq (http://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/shared_ptr.htm#functions): "A. 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.shared_ptr is "as close to raw pointers as possible but no closer"." BR, Dmitry

Dmitry Goncharov wrote:
Ray Logel wrote:
Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well.
For example: template<typename T> class protected_ptr { T * ptr;
// ... T * get(); const T * get() const;
// ... including operator* and operator-> }
class Foo { protected_ptr<Bar> _bar;
void Func1() { _bar->NonConstFunc(); _bar->ConstFunc(); }
void Func2() const { _bar->NonConstFunc(); // Compile error _bar->ConstFunc(); // Ok } }
Ray Logel
The could be useful to propagate constness, however it looks like the boost smart pointers deliberately dont do that. The following is an excerpt from shared_ptr's faq (http://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/shared_ptr.htm#functions):
This class would have no effect on the current implementation of shared_ptr, which I agree handles constness the way they should. It would only act as a protective wrapper around either a raw pointer or a shared_ptr when they are used as member variable and you would like to propagate constness within const member functions. When I suggested there could be a shared_ptr version as well I meant something like this: template<typename T> class protected_ptr { private: T * ptr; // .... } template<typename T> class protected_shared_ptr { private: shared_ptr<T> ptr; // ... }
"A. 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.shared_ptr is "as close to raw pointers as possible but no closer"."
BR, Dmitry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
David Abrahams
-
Dmitry Goncharov
-
Gregory Peele ARA/CFD
-
John Maddock
-
Ray Logel
-
Steven Watanabe