From: bouncer@dev.null   
      
   Seungbeom Kim wrote:   
      
   > On 2012-07-16 15:53, Wil Evers wrote:   
   >> Seungbeom Kim wrote:   
   >>   
   >>> On 2012-07-15 16:05, Wil Evers wrote:   
   >>>>   
   >>>>         template    
   >>>>         shared_immutable_ptr(std::unique_ptr consumed)   
   >>>>         : instance(std::move(consumed))   
   >>>>         { }   
   >>>   
      
   [snip]   
      
   >> The intent is that shared_immutable_ptr acts as a sink, taking   
   >> ownership away from the unique_ptr passed to its constructor.   
      
   [snip]   
      
   >>> How is shared_immutable_ptr different from   
   >>> std::shared_ptr?   
   >>   
   >> The difference is that there is a conversion from shared_ptr to   
   >> shared_ptr, while there is no conversion from   
   >> shared_ptr to shared_immutable_ptr.  The effect is that the T   
   >> instance passed to it is marked as const before it becomes shared.   
   >>   
   >> In other words, when compared to shared_ptr,   
   >> shared_immutable_ptr provides the additional guarantee that   
   >> there are no other smart pointers around that could act as a   
   >> backdoor for modifying the object pointed to.   
   >   
   > Sorry, I still don't understand. If you use std::shared_ptr   
   > instead of shared_immutable_ptr in your example:   
   >   
   >      std::unique_ptr build_a()   
   >      {   
   >          std::unique_ptr result(new A);   
   >          result->modify();   
   >          return result;   
   >      }   
   >   
   >      void f()   
   >      {   
   >          std::shared_ptr shared_a(build_a());   
   >          B b1(shared_a);   
   >          B b2(shared_a);   
   >          // ...   
   >      }   
   >   
   > there should still be no backdoor for modification. If you're   
   > considering what could happen to the result of build_a() before it   
   > binds to shared_a, the situation is no different for   
   > shared_immutable_ptr. Once an object of std::shared_ptr   
   > becomes the sole owner, there is no conversion from it to   
   > std::shared_ptr, so there can be no further modification.  Is   
   > this correct?   
      
   When we construct a shared_immutable_ptr from a unique_ptr, the   
   ownership of the object pointed to is transferred from the unique_ptr   
   to the shared_immutable_ptr.  Thus, we end up in a situation where the   
   shared_immutable_ptr is the sole owner of the object pointed to.   
   Since a shared_immutable_ptr cannot be used to modify the object it   
   points to, the object pointed to is now closed for modification.   
      
   As you illustrate above, a shared_ptr can be constructed from   
   a unique_ptr as well, with a similar effect.  But in addition, we   
   can also construct a shared_ptr from a shared_ptr.  This   
   overload is problematic, because we could end up in a situation where   
   the object pointed to has multiple owners, where at least one of these   
   owners can still be used to modify the object pointed to.   
   shared_immutable_ptr does not provide such an overload.   
      
   I agree that for the example above, there is no difference, but that   
   is only because we chose to use the right overload by directly   
   constructing a shared_ptr from a unique_ptr.  In   
   particular, if B's constructor takes a shared_ptr, it cannot   
   assume the A passed to it will not be modified.  In contrast, if   
   B's constructor takes a shared_immutable_ptr, it can.   
      
   Regards,   
      
   - Wil   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)