sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/05/89)
In article <9638@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > ... [ mainly about 'const' member functions ] > ... > >Right you are. I'll reiterate, though, that saying `this=this' >is a dangerous anachronism and should be avoided and ultimately >eliminated. In fact, I'm not sure what purpose it serves if it's >not in a constructor or destructor. What useful purpose can 'this=this' possibly have served even in a constructor or destructor? Help against some bug in earlier releases of cfront? This reminds me of some "highly optimising" but not too consistent Fortran compilers long ago: you sometimes had to insert such foolish-looking assignment statements into long linear code segments, otherwise they got compiled wrong. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
tk@allegra.att.com (Thomas Kirk) (09/06/89)
In article <1273@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: > What useful purpose can 'this=this' possibly have served even > in a constructor or destructor? Help against some bug in earlier > releases of cfront? ... no. in constructors of objects that do their own storage management (that is, by assignment to `this'), it is necessary that all execution paths through the constructor include the assignment. such constructors typically check to see whether the object was allocated on the stack or otherwise; `this=this' makes sense for objects allocated on the stack.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/06/89)
In article <TK.89Sep5145704@bebop.tempo.nj.att.com> tk@allegra.att.com (Thomas Kirk) writes: >In article <1273@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: > > What useful purpose can 'this=this' possibly have served even > > in a constructor or destructor? Help against some bug in earlier > > releases of cfront? ... > >no. in constructors of objects that do their own storage >management (that is, by assignment to `this'), it is necessary >that all execution paths through the constructor include the >assignment. such constructors typically check to see whether >the object was allocated on the stack or otherwise; `this=this' >makes sense for objects allocated on the stack. I am familiar with the additional effects of assignments to "this" in C++ versions so far (before 2.0); they are even described in Stroustrup's book. In my paper at ECOOP'88, "On the darker side of C++", I pointed out that the book's definitions about the matter don't work correctly in general with derived classes, and that releases 1.1 and 1.2 of "cfront" in fact did not follow those definitions but made an equally gross error in an opposite direction. It is the special case of 'this=this' that I still cannot see any sense in. Namely, if a constructor or destructor contains _any_ assignment to "this", the translator deduces that it wants to take care of its own memory (de)allocation, and thus does not generate a call to "new" or "delete". Why should there be, in addition to that meaningful assignment to "this", also 'this=this'? Even if it is on a different execution path, it does not accomplish anything there. (This discussion might still have some relevance: there is a lot of old software around, and it will be a long time before everybody gets Release 2.0 or equivalent). Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland