Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!radar!cadillac!vaughan
From: vaughan@puma.cad.mcc.com (Paul Vaughan)
Newsgroups: comp.std.c++
Subject: Re: Constructor can subvert constness (was ~const)
Message-ID: <VAUGHAN.91Mar25094127@puma.cad.mcc.com>
Date: 25 Mar 91 15:41:27 GMT
References: <NGO.91Mar21222244@tammy.harvard.edu>
Sender: news@cadillac.CAD.MCC.COM
Distribution: comp
Organization: MCC CAD Program, Austin, Texas
Lines: 78
In-reply-to: ngo@tammy.harvard.edu's message of 22 Mar 91 03:22:44 GMT


   From: ngo@tammy.harvard.edu (Tom Ngo)

   Twenty days ago, Reid Ellis <rae@utcs.toronto.edu> wrote:

   rae> Tom Ngo <ngo@tammy.harvard.edu> writes:
   rae> [Are there any ways to accomplish what casting away const does,
   rae> without doing so explicitly?]
   rae> 
   rae> How about this?
   rae> 
   rae> struct foo {
   rae>     foo();
   rae>     int sometimes() const;
   rae>     int nonconst();
   rae>   private:
   rae>     foo & fRef;
   rae> };
   rae> 
   rae> foo::foo() : fRef(*this) {}
   rae> 
   rae> Then, if say "sometimes()" needs to do a non-const thing, it can
   rae> simply say "fRef.nonconst()".
   rae> 
   rae> I guess this is essentially casting the const away, but the compiler
   rae> won't make a peep about it.

   Interesting!  This must be a violation of ARM 8.4.3 [References],
   which states:

       A reference to a plain T can be initialized only with a plain T.

   Assuming this rule is intended to apply to the initialization of a
   reference in a constructor, it seems you have uncovered an issue that
   really ought to be addressed in the ARM:  what is that status of a
   constructor with regard to constness?  Should it be made possible, as
   suggested by Jim Adcock <jimad@microsoft.UUCP>, for constructors to be
   specified as const?  If so, how would a const constructor be permitted
   to change data members?

Note that "const" in this context is a property of a pointer, not of
an object.  For instance

class Foo {
public:
  void bar() const;
  void nonconst();
};

Foo* global;

void Foo::bar() const {
 global->nonconst();
}

main() {
  global = new Foo();
  const Foo* f = global;
  f->bar();
}

It doesn't really make any difference that one example uses a global
and the other one uses a member. The point is, when the pointer (or
reference) was initialized, it was initialized with a non-const.  When
you realize that the Foo object isn't intrinsically const, you see
that nothing is really subverted, and no rules are violated. Also note
that the only way you can have intrinsically const objects (that is,
ones that might be stored in read only memory) is if they have no
constructor.
  

--

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
----------------------------------------------------------------------------------
I spent from $3 to $10 today to pay interest on the national debt.  How about you?
----------------------------------------------------------------------------------