[boost] Re: [smart_ptr] const-correctness as function argument

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-10-02 13:09:46

shared_ptr_const is abiguous as to whether it is analagous to shared_ptr<T>
const or shared_ptr<T const>.

"Larry Evans" <jcampbell3_at_[hidden]> wrote in message
news:3D9B312C.3080002_at_prodigy.net...
> scleary_at_[hidden] wrote:
>
> >>-----Original Message-----
> >>From: Larry Evans [mailto:jcampbell3_at_[hidden]]
> >>
> >>I haven't looked real close, but doesn't the subsection titled
> >>"Smart Pointers and const" in Item 28 of Scott Meyers
> >>_More Effective C++_ contain a solution to this problem?
> >>Basically, it describes SmartPtr<T>  derived from
> >>SmartPtrToConst<T> and SmartPtrToConst<T> containing
> >>a union of const and non-const pointers to T.  Unfortunately,
> >>this would require changing shared_ptr.
> >>
> >>
> >
> >That item is concerned with allowing a conversion of smart_ptr<T> to
> >
> But this is what D.Held wants, isn't it.  To be more explicit, let
> shared_ptr_const
> be the analog to SmartPtrToConst.  Then define:
>
>     void g (shared_ptr_const<foo>&p);
>
> then:
>
>     shared_ptr<foo> a_foo_ptr;
>      g(a_foo_ptr);
>
> would work as I think D.Held wants.
>
> >  The Standard solves the same problem in auto_ptr by the
> >use of templated constructors/assignment.  Boost solves that problem in
> >shared_ptr in essentially the same way as the Standard.
> >
> I think Held objects to this because Held wants to avoid "any needless
> copies".
> With the current shared_ptr, wouldn't the shared_ptr<foo> have to be
> converted to shared_ptr<foo const> via a copy constructor?
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>