Path: utzoo!attcan!uunet!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: operator++()   and   testing 'this'
Message-ID: <12148@cadillac.CAD.MCC.COM>
Date: 15 Oct 90 18:20:34 GMT
References: <1990Oct14.224706.1934@nowhere.uucp>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Organization: MCC VLSI CAD Program
Lines: 51
In-reply-to: sking@nowhere.uucp (Steven King)


   From: sking@nowhere.uucp (Steven King)

   In article <1990Oct9.144542.19983@sco.COM> jfischer@sco.COM (Jonathan A. Fischer) writes:
   >In article <706@msor0.UUCP> kt@msor.UUCP (Keith Tizzard) writes:
   >>Two questions about C++
   >>
   >>2   Testing of and assigning to 'this'
   >>
   >>Is it still possible to assign to 'this' in V2.0?
   >
   >	Technically, you can't assign to this, since it's "X * const this".
   >BUT, it's listed in Appendix B.3.3 as an "anachronism," something that is
   >provided for compatibility with earlier releases of cfront.  I.e., you can do
   >it, but technically you shouldn't.  Also, there is no requirement for a
   >compiler vendor to implement these anachronisms, so you are tainting your
   >portability by using them.
   >
   >>Can one rely on 'this' having the value zero on entry to the constructor
   >>if the object is allocated on the free store?
   >
   >	Yep, according to the same anachronisms section.

	   And only if the object isnt a member (or base) of another object.
   Even tho' the translator knows this information (it does pass a flag to
   destructors) there is NOT a reliable mechanism to determine this from within
   a constructor.

	   I wonder if there is enough of a need for this to consider adding it
   to the language...

Here's a related issue.  I'd like to be able to know if an object is a
member of another object.  For instance, I have a base "container"
class that maintains a table of objects that it owns.  I'd like to
provide automatic deletion of owned objects when the owner object is
destroyed.  But some of the owned objects are actually integral
members (and therefore are already automatically destroyed when the
owner goes) and some are allocated via new.  I'd rather not have to
store this info on the objects or provide for knowing it (although
your suggestion could allow for automatically recording that
information on the object in a transaparent way).  

I've thought about doing some pointer comparisons to detect whether an
owned object is within the address boundaries of the owner object.  I
have (or can automatically provide for) the information required to do
that, but it would surely be nonportable in the theoretical sense.
I'm not sure if its practical given the compiler set {g++, cfront } and
machine set {sun3, sparc, apollo}

 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