Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!mikem
From: mikem@otc.oz (Mike Mowbray)
Newsgroups: comp.lang.c++
Subject: Re: Interesting "Feature" of C++
Message-ID: <265@otc.oz>
Date: Sun, 25-Oct-87 17:59:10 EST
Article-I.D.: otc.265
Posted: Sun Oct 25 17:59:10 1987
Date-Received: Wed, 28-Oct-87 04:10:56 EST
References: <1787@dasys1.UUCP>
Organization: OTC Development Unit, Australia
Lines: 98

In article <1787@dasys1.UUCP>, wfp@dasys1.UUCP (William Phillips) says:

>> ... about a problem with changing "this" in a constructor. [ or elsewhere ]

Seems to me that it's not widely understood that "this" is special, (after
all, it's a keyword, not a normal variable), and should not be treated
simply as a pointer that you can do arbitrary things to. (At least not in
the current version of C++;- I recall a hint on the net some time ago that
assignment to this is being abolished in favour of something better.)

> I was in fact searching a list, finding an appropriate object, and
> assigning this to it (er, from it, I think!).

It makes a big difference. I assume that "this = something;" is what's meant.

> If the found object passed certain tests, it was modified slightly, but
> otherwise left alone; no problem.  If it failed those tests but passed
> others, I created a new object of the same class and (thought) I left
> the original alone; however, I found that the new object was fine, but
> the original one had been stripped down to its base class and
> consequently lost all its extra derived class information [...]

This would seem a highly inappropriate use of "this". Assigning to this
says that you want the current object (whose member function you're
currently inside) to become something else.

> I _had_ had the impression from some earlier attempts and what I could
> glean from <The ^**%$ Book> that once an object was constructed its
> class was cast in stone; apparently not so!

Well, it is unless one cro-bars cfront, asking it to make the object something
else, as is the case here.

> In fact, the reason I was using the " this = NULL " technique above was
> because I had tried to construct a base class object and then "recast"
> it into a derived class object after the fact.  Didn't work!

Once again, this would be a misunderstanding of what construction and objects
are all about. It's unreliable for the user to tell the compiler that he/she
now wants a certain object to be treated as something different. The way to
do this is to rely on derived class constructors. For example, one could
have a constructor derived::derived(base&) that makes a derived from a
base. Alternatively, it may be that the user has lost sight of the *real*
reason for wanting to do this sort of thing in the first place. Usually, it
is because some behaviour is desired from the object, dependent on what
type of object it is. A re-thinking of the problem, using virtual
functions, can solve this much more reliably and cleanly in a large number
of cases.

> Many of the problems encountered in learning C++ arise from the desire
> not to use object-oriented programming style. Similarly, most can be
> overcome by looking very carefully at whether one is trying to force
> certain behaviour based on the type of an object, without letting the
> compiler keep track of what the type is, by way of virtual functions.
> Note that in many cases, this is all that's required. - The programmer
> only wanted to know the type of the object so he could do something
> with it. This is largely solved by careful class design using virtual
> member functions.

> If you look at the C code generated by cfront (if you can stomach it :-),
> you will see that the assignment
> 
> 	this = NULL
> generates
> 	_auto_this = 0
> 
> ...and that's all
> 
> whereas an "inexplicit" assignment of this (such as  " this = funct() " )
> additionally generates code to reassign the virtual table pointer, which
> will cause severe distress if the value of this is something weird like 0.

I guess this is a hangover from the fact that there is one case when this=0 makes
sense, namely in the destructor. However, I am certainly eager to see something
better than the assignment-to-this method of user-controlled storage allocation.

> P.S.:  I have been told that <The Book> is (a)incomplete and (b)full of
> errors; I believe it.  It also doesn't have an index worth a damn.
> _wish_ Harbison & Steele would do for C++ what they did for C.

Ummm. Hang on. Let's put things into perspective. C++ is a large improvement over
C, and it's occasional shortcomings are second-order by comparison. Similarly, the
book is a large improvement over no-book, and, *if one follows the object-oriented
style of programming*, is quite good, although it could of course be improved further.
The more subtle aspects of C++ behaviour are not too difficult to discover from the
generated code. (I don't know why people are always complaining about the generated
code. - A few simple modifications to the +i option in the CC script produces code
that can be comprehended ok. I'll post these mods in a separate article.)

Regarding errors in the book, Bjarne posted a list of corrections some time ago.
Perhaps a re-post is appropriate?

			Mike Mowbray
		    Systems Development
			|||| OTC ||

	    ACSnet:  mikem@otc.oz	UUCP:  {uunet,mcvax}!otc.oz!mikem 
	     Snail:  GPO Box 7000, Sydney 2001, Australia