Newsgroups: comp.std.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: Dynamic type loss considered harmless
Message-ID: <1991Mar3.005515.18159@gpu.utcs.utoronto.ca>
Organization: UTCS Public Access
References: <1991Feb19.051123.5198@gpu.utcs.utoronto.ca> <27C2D4B8.3AD3@tct.uucp> <1991Feb25.201923.14554@gpu.utcs.utoronto.ca> <27CD13B1.649B@tct.uucp>
Date: Sun, 3 Mar 1991 00:55:15 GMT

In article <27CD13B1.649B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>Adding dynamic type information would entail significant changes to
>the meaning of "type".  Under current rules, a |Base| that is part of
>a |Derived| is indistinguishable from a plain |Base|.  Inventing a
>distinction between them would require rethinking the type conversion
>rules, especially in view of multiple inheritance.

You refer only to the byte storage that is associated with the type Base.

In behavior terms, the distinction is already there.  I can build a Derived 
that acts very similarly, or totally differently from its Base, through 
private inheritance, hiding members, or other means.  With virtual inheritance,
I can decide that several functions may share one copy of the Base part of
the object.

The distinction only matters if one is going to invoke type-specific behavior
in an application-specific context.  The type tag is necessary for those
cases.

>attitude that the feature is almost indepensible.  IMHO, it's not.

Every other object-oriented language has it, so burden of proof is on you.

>>Those other uses can be supported without requiring every object to carry
>>a type tag through to runtime.
>
>I don't see how, unless you are referring to the optimization that
>objects without virtual function tables do not maintain a type tag.

I do.  And objects that don't have virtual functions don't have any
potentially type-specific functionality.  So NO additional type tags
are required - we only want to see what's already there.

>>As it stands, you cannot add any type- and context-specific functionality 
>>to an object without access to its source code.  This greatly restricts
>>reusability, to a level between that of say, Eiffel, and that of Ada.
>
>"Well, don't do that, then."  If I can't modify the source code to a
>class, I may use use it, but I usually won't derive from it.

Then you will never extend anyone else's code, use a framework, etc.  It
seems we have found the source of our disagreement.

You want a "better C".  We want a "reusable library language".  I would
suggest that if we can get what we want without imposing any overhead on
you (in fact removing some), you should stop arguing with us.  :)

>>I do not consider this sufficient to support a components industry, as it
>>leaves too many ways for producing programmers to cut off options for those
>>building on their code.
>
>IMHO, any attempt to distribute binary-only C++ components intended
>for use _as_base_classes_ is probably doomed to failure in all but the

If true, I would suggest that C++ itself is probably doomed to failure too.
No need to argue this point, we have been over it already.
 
>simplest cases, for reasons that go far beyond the lack of dynamic
>typing.  Adding a type tag won't solve the problems of non-virtual
>member functions and private (as opposed to protected) members.

Why are private members a problem ?  The guarantee a programmer makes in
providing public members are that they are sufficient to do whatever the
object is supposed to do - access to privates is in principle unnecessary.
If this is untrue in some cases, then the member should be protected or
(more likely) the functionality redefined.

>So C++ isn't a good language for binary components; so what?  If I
>want Objective-C, I know where to find it.

As I say, we've been over this already.  Objective-C has its own problems.

I would think you are in a minority in not wanting C++ to support binary
components.  I would appreciate hearing from others on this point.  On
this question I think we must agree to disagree.
-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig