From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 17 Jul 92 19:12 MDT
Subject: Re: Covariant Types in Derived Classes
Nf-ID: #R:1992Jul10.172914.1257@cadsun.cor:209035750:1992Jul17.151205.26066@ucc.su.oz:1876133037:001:6931
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 19:12:00 1992


In article <1992Jul15.192628.1891@cadsun.corp.mot.com> shang@corp.mot.com writes:
>> In article <1992Jul14.192525.24284@cadsun.corp.mot.com> shang@corp.mot.com  
>writes:
>>
>> >The first one is to view run time type check as an overhead. It is not. It 
>> >is a necessity. 
>
>In article <1992Jul15.130307.28112@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
>(John (MAX) Skaller) writes:
>> 
>> 	I would say this backwards: IF it is necessary,
>> 	THEN you must incur the overhead.
>>
>
>When I say it is necessary, I don't mean it is always necessary. But as a  
>general purposed language, it should include a facility when it is necessary in  
>some *common* case.

	OK. Suppose I accept this argument. I need then to 
	see a common case. You assert that het. aggregates would
	benefit from this but I assert they are never required.

	Therefore, from a given design requirement you need to
	show that it can be done no other way.

	I agree there might be such cases, by the way.
	[Exceptions appear to be one of them, for example!]

	But I have not seen such a case.
> 
>> >It is the common case that you have to run time check whether an  
>> >index is overflow the range of a array. 
>> 
>> 	On the contrary, in C++ it is the case that you CANT do
>> 	a run time type check on an array! (At least
>> 	not automatically using built in arrays)
>>
>
>What C++ can't do is not what the real world should not have. 

	Yes, and what C++ doesn't yet have might not have to
	be what it never has :-)

	So we have similar goals here but I am not convinced.

>Besides, I am not  
>talking about automatic run time index check.

	This is a case where we MIGHT be able to have  checking
because there is no other way. But that is another story.
> 
>> >And it is also a common case that you  
>> >have to run time check what the type of the object is in order to perform 
>> >the appropriate operations, 
>> 
>> 	It is not common in my programs. I have never had to do 
>> 	this.
>> 
>
>Be realitic, please. What you have not is not what others have not either.

	I am being realistic. I do not have this need because I do
not design systems that require heterogeneous aggregates.

	I aspire instead to design systems using mixin techniques,
which replace the concpet of 'heterogeneous' aggregates with
that of 'anonymous' types.

	Now by say keeping a master array of all objects,
and arrays of pointers (all of the same base class),
the heterogenaety is obtained without ANY run-time type
operation: it is obtained at object contruction
time by the maker of the object (who is the only
one who knows the actual type, and who dies shortly
after the object is created)

	Suppose for example you have abstract base classes
A1, A2, ... AN.

	You make an object by mixing the abstractions

	class A : public virtual A3, public virtual A7 { ..

	And a concrete example by

	class D : public virtual A, .....

	Now you say

	D* d=new D;

And you can add the pointer to arrays of pointers to A3 and A7.
[Also a root owner class perhaps to control object life,
perhaps with reference counting ? ]

NOW if you want all the objects with property A3, you already
have them. 

>
>> >especially for heterougeneous data structures. 
>> 
>> 	Yes, so if your design is base on heterogeneous aggregates,
>> it is probably faulty. C++ can't handle them, and I argue MOST of the time,
>> they are not required.
>>
>
>Now, you see what you have not seen before. 

	I have seen many people try to write C++ this way.
It can only bring grief. There are other ways to handle systems
of objects of many types than lumping them all togther in
a basket, forgeting what type they are, then asking later,
"What type are you, sorry, I forgot".

	I have suggested one above. There are surely others.
I have used the technique above to build a model of a chemical
plant. [Using dynamic linkage also] Here there are many
objects, some containing or transporting chemicals,
others are fences and bund walls.

	There is a list of all objects.

	There is a list of all objects of each type as well.

	There is a list of all drawable objects.

	Maintaining the lists is the 'run-time' overhead
required to remember the type: it happens once at
construction time.

	Run time type check, on the other hand, is done
on all accesses. My method is much faster during operation,
yours faster at construction time.


>The real world is full of  
>heterogeneous aggregates. But don't blame the real world just because C++ can  
>not handle them,.
> 
>> >For  
>> >example, if you want to write an operation on a heterougeneous object 
>> >stream, a window chains with different window types,...
>>
>> 	No, the programmer must not make such aggregates. 
>> 	It is a misuse of inheritance.
>>
>
>I'm talking about run time type check, not the inheritance. 
>I know what you try  
>to say: a heterougeneous aggregate can not be specialized, right? 

	I dont understand.

>If you try to  
>specialize a heterougeneous aggregate in the class hierarchy, you misuse  
>inheritance. But it is not the point that relates to run time type checking.  
>And besides, a sound language should prohibit specializing heterougeneous data  
>structure. Unfortunately, C++ does not distinguish what is homogeneous and what  
>is heterogeneous.

	Yes it does. Arrays of objects are homogeneous. 
	Arrays of pointers must point to objects of the same base type.
> 
>> 	The concept of 'thisclass' is useful. No argument!
>> 	But it does have disadvantages [As does power operator, no doubt]
>
>But you did not gave me any covincing argument on the disadvantage.

	I am not trying to prove run-time type check is wrong, useless,
bad or unnecessary. But I *AM* saying that it is not correct to
use this facility for heterogeneous arrays (EVEN if ANSI gives
us that power)

	It is up to you to find what I consider legitimate uses
if you want to convince me. I will think on it and post any that I think of.
>
>> 	And proper multiple dispatch would include it as a special case.
>>
>
>What is your proposal of a proper multiple dispatch? 

	Dont know. It would need run-time type information
perhaps.


>I cannot see anything that  
>binds the two concepts together. If there is, it is the COMPLEMENT: "thisclass"  
>is used to specify the component whose type is the same as the type of the  
>enclosing object, while multiple dispatch requires the argument whose type is  
>INDEPENDENT to the type of the enclosing object type. 
>   

	"Thisclass" is but one of the possible combinations
multiple dispatch would support, the others too, with the user
controlling which were valid, what they meant, and which were
errors.
>
>David Shang


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

Newsgroups: comp.lang.c++