Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-03 23:32:21


"David B. Held" <dheld_at_[hidden]> wrote in message
news:bt827b$hvp$1_at_sea.gmane.org...
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message

[snip]

> > I think there is. It's a giant loophole in the general const-correcness
> > of all programs.
>
> Then let me try to convince you otherwise with an example:
>
> void log(std::ostream& s, int x);
>
> class foo
> {
> int x_;
> public:
> int x(void) const { log(some_log, x_); return x_; }
> };
>
> Is this code not const-correct?

I don't see your point, but yes. If we have a const member functions I want
(and many others)
constness to propagate to members pointers or not. If an argument is const,
I don't wan't to change the argument <g>.

> It looks like you are missing the fact that const smart_ptr<T> is
> really analogous to T* const. Now, if you are arguing that T* const
> should be the same as T const*, that's an entirely different ball of
> wax.

I'm certainly not trying to do that.

> But I'm still not convinced.

Instead of thinking about syntax, think about usefulness. I have repeatedly
asked for real examples where
the current behavior is really needed and none has come up with them.

The current design is biased towards one way of thinking and the problems
are:

1) Many people don't like that behavior
2) Those people can't get what they want easily
3) If the design is changed, those who favor the current design can get what
they want easily
4) The property that const smart_ptr<T> must absolutely be equal to T* const
has not been justified
    in any way; It seems that the use for it is seriousely limited

If you add to this that smart pointers is going to be used in almost any
future C++ program, it should
be serving most people needs. I have no intension to prohibit those who
wan't to bypass the type system,
but I would appreciate that I can use it if I wan't.

So please, let us discuss these core issues.

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk