Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at