rick@triode.apana.org.au (Richard Welykochy) writes:

>I'm wondering about a different mechanism for 'mutable'.
>i.e. specify a method as mutable: it is const to
>the clients of the class, but the implementation is
>non-const.  This is simpler, since the mutability
>is now on a method-by-method basis, i.e.

I don't see what it buys you.  How is it simpler?

>class XXX  // another way to mutate
>{
> int a;
>    int cnt;
>public:
> int f() mutable { cnt++; return a; }
> int f2() { return a; }
>};
>
>XXX const x;
>int i = x.f(); // fine
>int j = x.f2(); // error

Why is that any better than this?

 class XXX
 {
  int a;
         mutable int cnt;
 public:
  int f() const { cnt++; return a; }
  int f2() { return a; }
 };

 XXX const x;
 int i = x.f(); // fine
 int j = x.f2(); // error

>The class client can see at a glance which methods
>are logically const (i.e. those marked 'const' and 'mutable')
>and those which are not (all others).

But with the standard use of mutable, the class client even more easily
see at a glance which methods are logically const - it's just
those that are marked 'const'.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <3j1gqg$1nl@triode.apana.org.au>,
Richard Welykochy <rick@triode.apana.org.au> wrote:
>
>Stroustrup proposed the following to allow one to
>modify data in const methods:
>
>class XXX  // from p.287 "The Design and Evolution of C++"
>{
> int a;
>    mutable int cnt; // never const
>public:
> int f() const { cnt++; return a; }
>};
>
>I'm wondering about a different mechanism for 'mutable'.
>i.e. specify a method as mutable: it is const to
>the clients of the class, but the implementation is
>non-const.  This is simpler, since the mutability
>is now on a method-by-method basis, i.e.
>

 The committee decided to implement a complete hack
instead of a proper mechanism based on type notions. Sorry.
mutable is a storage class specifier. The original proposal
was for

 ~const
 ~volatile

and there were fears this would interact with the type system.
Of course, that is exactly what it should do. Mutable does
interact with the type system, but it is not extended to

 int mutable*

or mutable member functions. On the other hand

 T ~const*

makes perfect sense, as do ~const member functions.
Don't expect orthogonal design from a committee :-(
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Stroustrup proposed the following to allow one to
modify data in const methods:

class XXX  // from p.287 "The Design and Evolution of C++"
{
 int a;
    mutable int cnt; // never const
public:
 int f() const { cnt++; return a; }
};

I'm wondering about a different mechanism for 'mutable'.
i.e. specify a method as mutable: it is const to
the clients of the class, but the implementation is
non-const.  This is simpler, since the mutability
is now on a method-by-method basis, i.e.

class XXX  // another way to mutate
{
 int a;
    int cnt;
public:
 int f() mutable { cnt++; return a; }
 int f2() { return a; }
};

XXX const x;
int i = x.f(); // fine
int j = x.f2(); // error


The class client can see at a glance which methods
are logically const (i.e. those marked 'const' and 'mutable')
and those which are not (all others).

I've used a similar technique to provide mutability:

class XXX  // mutable keyword not yet available
{
 int a;
    int cnt;
public:
 int f() const { Mutable().cnt++; return a; }
private:
 XXX& Mutable() const { return const_cast<XXX&>(*this); }
};

This really captures the essence of a mutable method,
rather than a mutable data member, i.e. const methods
that emply Mutable() are themselves logically const.

Any ideers? Comments? Flames?

P.S. I noticed that J.Fleming has postponed the Unirversity
course.  I think we scared him off the internet. Sigh.

>In article <3j1gqg$1nl@triode.apana.org.au>, rick@triode.apana.org.au (Richard Welykochy) says:
>
>P.S. I noticed that J.Fleming has postponed the Unirversity
>course.  I think we scared him off the internet. Sigh.
>

No, you have not "scared me off the internet" or INNERnet as I now
call it. We are in the process of setting up the OuterNet which will
be based on distributed object technology and which will have "gateways"
to the Internet.

Jim Fleming
Unir Technology, Inc.
Naperville, IL 60563