Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Responses to ~const 1.6: Alternatives to ~const
Message-ID: <71089@microsoft.UUCP>
Date: 6 Mar 91 20:26:31 GMT
References: <NGO.91Feb19113232@tammy.harvard.edu> <1991Mar1.094159.40@alias.uucp>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 24

In article <1991Mar1.094159.40@alias.uucp> Reid Ellis <rae@utcs.toronto.edu> writes:
|How about this?
|
|struct foo {
|	foo();
|	int method() const;
|	int sometimes() const;
|	int nonconst();
|private:
|	foo & fRef;
|};
|
|foo::foo() : fRef(*this) {}
|
|Then, if say "sometimes()" needs to do a non-const thing, it can
|simply say "fRef.nonconst()".
|
|I guess this is esentially casting the const away, but the compiler
|won't make a peep about it.

Seems to me some compiler someday could choose to howl about this
constructor when envoked for a const foo.  It also seems to me that
you point out a weakness in the language -- it should be possible 
to specify whether constructors are const "functions" or not.