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.

Background information to this posting was in a very recent summary.

Is ~const really needed?  I have scoured the replies, looking for
alternative ways to accomplish similar objectives without extending
the language.  The most obvious way to achieve the functionality of
~const is to cast constness away on a case by case basis.  The only
other alternative was described by Jim Adcock <jimad@microsoft.uucp>,
who brought up the following suggested scheme, mainly to show
how absurd it is.

Say you want to implement the equivalent of ~const data members.  If
you want to avoid casting away const, which is implementation-
dependent, you have to set up two classes which are <identical in all
respects except that in one, all members are non-const, and in the
other, all data members are const except the ones that you want to
behave as if they were ~const.  Then when what you want is the const
version of the class, you declare an object of the latter class;
otherwise, you declare an object of the former class.

Then if you want to make things a bit neater, you can declare two
smaller classes: one with all the members that are always ~const, and
the other with the members that can be other const or not.  This makes
it easier to maintain consistency between the two classes of the
previous paragraph.

Are there any other alternatives?
--
  Tom Ngo
  ngo@harvard.harvard.edu
  617/495-1768 lab number, leave message

Tom Ngo <ngo@tammy.harvard.edu> writes:
>.. you have to set up two classes which are <identical in all
>respects except that in one, all members are non-const, and in the
>other, all data members are const except the ones that you want to
>behave as if they were ~const.
...
>Are there any other alternatives?

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.

     Reid
--
Reid Ellis  176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada
rae@utcs.toronto.edu        ||  rae%alias@csri.toronto.edu
CDA0610@applelink.apple.com ||             +1 416 446 1644