Re: FW: converting shared_ptr<const T> to shared_ptr<T>

From: Lois Goldthwaite (loisg_at_[hidden])
Date: 2001-03-03 05:39:58

Member template constructors can not be used to replace the ordinary
copy constructor and assignment operator (12.8p2). If you don't provide
these functions, the compiler should synthesize them for you. I don't
know what VC does in this situation.

Lois

> Message: 4
>    Date: Fri, 2 Mar 2001 21:28:41 -0600
>    From: "Ed Brey" <brey_at_[hidden]>
> Subject: Re: FW: converting shared_ptr<const T> to shared_ptr<T>
> 
> From: "Trevor Perrin" <tperrin_at_[hidden]>
> >
> > shared_ptr<int>       C = new int;
> > shared_ptr<const int> D =C;
> 
> With a conforming C++, this will work.  However, VC6 has problems with
> member templates, and so the functions that allow this to work are excluded
> by the preprocessor.  However, it is possible that Boost.SmartPointer can
> make better use of what does work with VC6.
> 
> For example, the following changes to will make your example to compile (and
> presumably work):
> 
> Change the conditional compilation expression in class shared_ptr to:
>   #if !defined(BOOST_NO_MEMBER_TEMPLATES) ||
> defined(BOOST_MSVC6_MEMBER_TEMPLATES)
> and move
>   shared_ptr(const shared_ptr& r)
> and
>   shared_ptr& operator=(const shared_ptr& r)
> into the #else portion of the conditional block.
> 
> Changing the expression allows VC6 to see the member templates, and moving
> the non-templatized constructor and assignment operator works around a VC6
> bug in which it sees the templatized and non-templatized functions as
> conflicting duplicates.  Moving the non-templatized versions to the #else
> causes them to only be seen by compilers for which no member templates
> whatever are supported.  AFAICT, the non-templatized functions should have
> never been there in the first place when member templates are compiled since
> they add nothing that the templatized functions don't already provide.
> 
> Beman, others, does this analysis make sense?  Am I missing/forgetting
> anything?  Should we make this change to shared_ptr, and then also imbue
> shared_array with this functionality (Trevor's example is just as applicable
> to arrays)?  Finally, does anyone know if there are any issues with VC6
> silently generating bad code that relate to this situation?
> 
> 
>