Re: [boost] Re: Interest in smart pointer with value semantics?

From: Dave Harris (brangdon_at_[hidden])
Date: 2004-01-05 10:17:13

In-Reply-To: <bt89ob$qbg$1_at_[hidden]>
dheld_at_[hidden] (David B. Held) wrote (abridged):
> You still haven't shown how smart_ptr<T const> does *not* give you what
> you want.

For me the problem arises with member variables, and it arises with plain 
pointers. For example:

     struct S {
         MyClass c;
         MyClass *pc;
         void demo1() {
             // I want c and *pc to be non-const here.
             // Both OK.
         }
         void demo2() const {
             // I want c and *pc to be const here.
             // C is OK, but *pc is non-const.
         }
     };

I sometimes want the pointer and the direct object to behave the same with 
respect to const. Often they both represent the same kind of relation, 
with the pointer version being chosen for dependency management, or 
because I need polymorphism, or lazy initialisation, or whatever - reasons 
that have nothing to do with const. That switching from c to *pc switches 
off const is an unwanted, potentially dangerous side effect.

Smart_ptr reproduces the plain pointer behaviour and so reproduces this 
problem. I think that is correct for the default smart_ptr. However, I 
would appreciate another kind of pointer which offered deep const, for use 
where appropriate. This:
    smart_ptr< const T >

is /not/ what I want. This would have *pc being const even in non-const 
member functions.

I think it would be OK if the deep_const pointer had deep copy semantics. 
In practice I sometimes want deep const without deep copy, but then I 
don't want copy at all. If this variant is named deep_copy, I hope that it 
will not actually require its object to be copiable.

So perhaps deep_copy is the wrong name. I suspect the underlying issue 
here is whether the pointer represents a "part of" or a "uses" 
relationship. If it is "uses", then copying should be shallow and const 
not propagated. If it is "part of", then copying should be deep and const 
should be propagated. C uses the same pointer mechanism for both kinds of 
relationship, but in C++ we can do better. Perhaps the pointer I am 
looking for should be spelt:

    smart_ptr< const T, part_of >

-- Dave Harris, Nottingham, UK