From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 29 Apr 92 00:27:31 GMT
From: ssc-vax!dano@beaver.cs.washington.edu  (Dan Olson)
Subject: Re: Ada vs. C++ Paper (was Re: Why ADA?)
Message-ID: <5200@ssc-bee.ssc-vax.boeing.com>
List-Id: <comp.lang.ada>

Just want point out that I don't believe the following problem, as I
understand it, exists.

In article <1992Apr20.162724.7037@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.e
du (Harry Koehnemann) writes:
>	EIFFEL					C++
>
>class A feature func		    |	class A { Public int func; };
>    ....			    |
>				    |
>class B feature func, a_func	    |	class B : Public A {
>    Inherit A			    |		Public int func; };
>	a_func renames func	    |
>    ....			    |
>				    |
>  Have access to X.func, X.a_func   |	Have access to X.func and X.A::func
>			 ^^^^^^^^				  ^^^^^^^^^
>
>Forgive the syntax.
>The user of B should only know what features B offers, not how they are
>being offered.  In C++, one is forced to include the class name A in any
>reference to A's func through class B.  This means that if this relationship
>between B and A changes, anyone using B will need to be modified as well.
>This does not sit well with information hiding.

If information hiding is what you want, then in C++, class A's func()
inherited by class B should be private to B.  If access to A's func()
as inherited by B needs to be available, but you still want the fact
that it came from class A hidden, then a little wrapper can be
provided that renames it to something besides "func".

Example:

class A {
public:
  void func() {cout << "A" << endl;}
  };

class B : private A {
public:
  void func() {cout << "B" << endl;}         // B's own func
  void func1() {A::func();}                  // provides A's func as func1
  };

main()
{
  B b;
  b.func();                // Calls B's func()
  b.func1();               // Secretly calls A's func()
  b.A::func();             // COMPILE ERROR - A's func() is not available
}

>Multiple inheritance makes
>these problems even worse - what happens when a class C inherits fomr A and
>B, and then defines it's own func.  This type of renaming w/ multiple
>inheritance led to internal compiler errors in the Eiffel compiler I used.

Again, this is not a problem.  Or am I missing your point?

What are some of the other "Big Time Problems" with C++ that were
brought up in the paper?  There were design trade offs that definitely
make it poor is some areas, especially the lack of many of the neat
features you get with Smalltalk and Lisp Flavors, but I still like
programming with it.

BTW, I just started a project using ADA and I think it also is a
fine language, just different.
-- 
dano  [] UUCP:      ..!uw-beaver!ssc-vax!dano
      [] Internet:  dano@ssc-vax.boeing.com
"Once the game is over, the king and the pawn go back in the same box."
- Italian Proverb (I think)