Re: [boost] Summary: converting shared_ptr<const T> to shared_ptr< T>

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-09 07:09:46

----- Original Message -----
From: "Ed Brey" <brey_at_[hidden]>
> 1. Even though MSVC's member template support is non-conformant, it is
> possible to use what does work to allow construction and assignment to a
> shared pointer from a different but compatible type.  This is achieved
> by using a base class, which prevents MSVC from thinking that a member
> template has already been defined.

Yep, this is the technique we used for debug iterator templates in STLport.

> 2. Using member templates in VC has been reported to cause problems with
> regard to exporting from a DLL.  The exact nature of the problem, if
> any, has not been identified.  New info (non-summary): I tried using a
> smart_ptr from the existing (no member templates) code in an exported
> class, and VC gave me a warning straight away that there would be
> problems, so it appears that DLL exporting is a separate significant
> problem.
>
> 3. Shared_array currently does not support construction or assignment
> from compatible types.  In this context, compatible means types with
> less restrictive cv qualifiers.  The can be remedied through various
> methods, of which using static assertions and the is_same type trait is
> the most portable to nonconformant compilers.
>
> Attached is an updated version of smart_ptr.hpp and, for convenience, a
> diff versus the existing version.  A couple notes on the updated
> version:
>
> a. I have only lightly tested it with VC and gcc.  It should be reviewed
> and regression tested across supported platforms.
>
> b. The workaround mentioned in item 1 above is guarded in conditional
> compilation so that it only gets applied to MSVC.  The reflects my
> opinion that minimizing the complexity of code that is compiled on a
> conforming platform is worth a small amount of code duplication.
> However, others may weight avoidance of code duplication more heavily,
> which is also fine.

Looks terriffic to me. I recommend that we accept this version as soon as we
feel the tests are robust enough.

-Dave