[boost] Re: ClonePtr and CopyPtr take 2

From: Stephen Cleary (scleary_at_[hidden])
Date: 2000-03-13 10:49:08

darin adler wrote: 
> > does that answer your question?
> 
> You seem to be confused between a pointer that is const and a pointer
that
> points to an object that is const.
> 
> A pointer that is const -- means the pointer can not be re-seated:
> 
>     T * const
>     const scoped_ptr<T>
> 
> A pointer that points to an object that is const -- means the object
can not
> be modified (only const member functions, etc.):
> 
>     const T *
>     scoped_ptr<const T>
> 
> A pointer that is const and points to an object that is const:
> 
>     const T * const
>     const scoped_ptr<const T>
> 
> Your proposal seems to blur and mix these.
> 

I think that he knows the difference.  The problem here is two
different design philosophies.  I've been reading B&K finally (& loving
it!  *Everyone* should read!) and just before their description of
their versions of ClonePtr and CopyPtr, they spend a short time
discussing how pointers are used.

I don't have their book here right now, but the idea they describe is
something like this:  Pointers (usually smart pointers of some type)
are often used for what they call "referencial aggregation", which is
an object A that contains a pointer to another object B, but it's
understood that in the *design*, A really contains B (not just refers
to it).  Of course, CopyPtr & friends are perfect for this, since each
CopyPtr has its own copy of the B object.

Now comes the funny part.  If A *actually* contained B, then a const-A
automatically restricts its B subobject to const-ness.  This does not
hold for objects pointed to by pointers in A.

If smart pointers are being used for referencial aggregation, then the
* operator *should* return "B &" or "const B &", depending on the
const-ness of the smart pointer (which is the const-ness of A).

OTOH, if the smart pointer is not being used for referencial
aggregation, we would prefer to have the same semantics as a built-in
pointer.  (Or would we?)

I've run into this before, but have not been able to devise a good
solution.  I don't like splitting up our smart pointers into several
dozen classes with hard-to-remember naming schemes or obscure template
parameters.  So I guess I don't have a solution; this is just a
description of the problem.

        -Steve