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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-03 20:47:14

"David B. Held" <dheld_at_[hidden]> wrote in message
news:bt7931$u7g$1_at_sea.gmane.org...
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> news:bt6ed9$hh6$1_at_sea.gmane.org...
> > [...]
> > :-) it depends on one's definition of const-correctness. I'm talking
> > about *propagation of constness* within const member functions,
> > not unconditional constness.
> >
> > This is the only meaning of const-correctness that I have seen.
>
> I've never seen "propagation of constness" mentioned in any
> definition of "const correctness".  Sometimes a const member
> function will only call const functions, and sometimes it won't.

I can except that some people want to do that. But I think the
two forms of thinking should be supported equally well. That is not the
case.

> I think you're misled by the fact that a const member function
> can only call other const *member functions*.  But there is nothing
> intrinsically wrong with a const member function calling a non-
> const free function.

I think there is. It's a giant loophole in the general const-correcness of
all programs.

>Anyway, I don't see what your problem is
> with the smart_ptr<T const> syntax.  It causes operator->() to
> return a T const*, which is just what you want, right?

Not quite. I don't want it to return a const  T* unconditionally.
In the current situations, people in favor of non-const correct programs
get what they want. I'm left with two scenarios

1) writing a new wrapper around existing smart pointers
2) in generic code, const T* and const smart_ptr<T> are not equal and I will
need traits to deal with different syntax

Neither is particular attractive.

> And you
> can create a smart_ptr<T const> from a smart_ptr<T>, just like
> you can create a T const* from a T*.  So, *if* you can do what
> you think is the Right Thing(TM), then why does it matter that
> you can also do things another way, which you might think is
> not the Right Thing(TM)?

Sure, I can do it, but if it is too inelegant, me (and nobody else) will use
it. As I see it,
the work-around for me is very trouplesome whereas the workarounds
for removing constness are trivial. **Therefore const-propagation should be
the default**.

workaround 1) use mutable: This must be the most elegant and
self-descriptive solution.

workaround 2) provide a special member function that does not propagate
constness, eg ptr.mutable().

The fact that the pointer would not work as a builtin pointer is not
important. If it is, it needs to be proven that
it is.

The fact that good library components should support as wide an audience as
possible is important.
The current way of implementing smart pointers totally neglects this.

br

Thorsten