Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: Inheritance & type conversion
Message-ID: <1991Jun14.100558.3061@jyu.fi>
Date: 14 Jun 91 10:05:58 GMT
References: <2348@taurus.cs.nps.navy.mil> <761@taumet.com>
Organization: University of Jyvaskyla, Finland
Lines: 79

(Arrrgh: I already wrote and submitted something like this yesterday,
but some testing of the news system here caused all articles to get lost.
Worse, the previous - in my opinion incorrect - answer to the original
question that I had commented on, has expired in the meantime.)

In article <761@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:
>
>>There are two classes, Base and Derived.
>
>>Derived is derived from the Base class and has a method to do a
>>	type conversion from Derived TO Base.

The comment that I lost said that there is never any need for such
a conversion.  That is not quite true:  if the semantics of the default
assignment operator or copy constructor called ("slicing" below)
is not what is desired, one has to write a conversion function.

>>Base has friends functions, report1 and report2.  Report1 takes a
>>	reference to a Base, report2 takes the value of a Base,
>>	as the parameter.
>
>[
>  sometimes the user conversion from Derived to Base is called for
>  only one function, sometimes only for the other, depending on compiler.
>]

Skip Carter said that when the functions were invoked on an actual
parameter of declared type Derived:
- with 'report1', Turbo C++ invoked the conversion, Zortech C++ did not.
- with 'report2', Turbo C++ did not invoke the conversion, Zortech C++ did.
In both cases, I claim that Zortech is right and Turbo C++ wrong.

Some years ago, Turbo Pascal seemed to be a lot more Turbo than Pascal
on several aspects.  Maybe that is the current situation with Turbo C++?

>The problem is that the language specification defines how a derived
>class is converted to a base class and under certain circumstances
>must result in a slice of the same object.  That is, under some
>circumstances the conversion must NOT call a user conversion function.

I don't believe this.  The language specification defines only the
default conversion that is applied IF no user-defined function exists.

>Some cases are (at the moment) undefined as to whether a user conversion
>will be called.  This leaves room for different results from different
>implementations.

I don't believe this either.  Can you cite the pertinent sections
of the ARM?

>Therefore, it is bad practice to declare a user conversion from a
>derived to a base class, since it sometimes will not be called.

Well...  There _is_ one problem caused by the fact that C++ supports
only single polymorphism (late binding takes into account only the
dynamic type of the 'self' object, although compile-time polymorphism
considers the types of all parameters).  The problem was illustrated
in part by 'report2' above.

Note that whenever any conversion function is applied, it yields
a _new_ object as its result - there is no way in C++ to change
the type of an object so that it remains the same object.
Therefore, if a conversion were applied to a reference parameter,
the effect would actually be that of a value parameter.
_That_ would be truly treacherous.

----------------------------------------------------------------------
"All similarities with real persons and events are purely accidental."
      official disclaimer of news agency New China

Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------