Re: Ada vs. C++ Paper (was Re: Why ADA?)

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[Larry M. Jordan]

>Possibly the strongest conclusion in the paper is that the inheritance
>feature in C++ is extremely tricky to use, and can lead to big time problems.
>I asked him if he still feels this way, and he said he does, more so
>even than before. ...

Anyone care to enumerate some of these so called "big time problems"? 
Is the problem with inheritance in general (is Eiffel subject to these
same problems?  Turbo Pascal 5.5+?) or with inheritance coupled with
dynamic binding?

Does the paper talk at all about C++'s lack of "packages"?  This strikes
me as a much bigger problem than "inheritance".

--Larry %)

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[micro-heart-of-gold.mit.edu!news.bbn.com!usc!elroy.jpl.nasa.gov!aero.org!]

>One problem with C++'s inheritance is naming conflicts.  If an operation
>is given by a parent and a grandparent have the same name, the user must
>explicitly name the grandparent in the call if they wish to invoke that
>operation.  This completely violates the infoirmation hiding OO was
>supposed to provide us.  What happens when we redesign that parent/
>grandparent - all the users of that class must be rewritten.  No, Eiffel
>does not suffer from this problem (a name can only propagate out of a
>class with one meaning).  You use the renames construct to change the
>name you're exporting - don't know about TPascal.

I think you are describing invoking an overridden or redefined method.
(Please correct me if I've misunderstood.)
The redefined method must be qualified with the class name, or one gets
the redefining method.  Has Eiffel changed? I thought renaming was 
done in the INHERIT clause (by the inheriting class, not the defining class).  
 
Will a renaming declaration, as I've seen proposed in ARM, fix this
"problem" (I'm still not convinced).?

Does Ada "violate information hiding...", since a name can "propogate out 
of a [package] with more than one meaning"?   

--Larry %)

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[Xmiester]

>
>One problem with C++'s inheritance is naming conflicts.  If an operation
>is given by a parent and a grandparent have the same name, the user must
>explicitly name the grandparent in the call if they wish to invoke that
>operation.  This completely violates the infoirmation hiding OO was
>supposed to provide us. 

Isn't this a contradictory statement ?  If you're trying to access
a grandparent of a class you inherit from, you've thrown away *information*
hiding right off the bat.



-- 
John Goodsen
goodsenj@ajpo.sei.cmu.edu

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[eru.mt.luth.se!lunic!sunic!lth.se!newsuser]

In article <1992Apr16.141200.1@vaxr.llnl.gov> edmunds@vaxr.llnl.gov writes:
>
>    He also told me a quote from Bjarne Stroustrup to the effect of --
>"In C++ it's harder to shoot yourself in the foot, but when you do, you
>blow off your whole leg."

Bjarne Stroustrup is well-known for his amusing comments on C++.  Here
is another one that Bjarne told me, although he didn't invent it:

	"C++ is the C of object-oriented programming languages."

Well worth a chuckle.  If you think twice about it, I think it
captures much of what is good and bad about C++.

Does anyone know a similar one about Ada?


		-- Dag Bruck

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[Bjarne Stroustrup]

Hmmm. I won't disturb this happy C++ bashing for long, but for people
who would like to get a more accurate view of what C++ is I would
recommend:

	Bjarne Stroustrup:
	The C++ Programming Language (2nd edition)
	Addison-Wesley 1991.

and for a wide range of experiences, applications, and opinions

	Proeedings of the USENIX C++ Conferences

Some reading along those lines would give you some idea why - right or
wrong - some people feel compelled to inform you about C++'s supposed
failings.

I certainly find it hard to recognize C++ in some of the "information"
offered here. C++ isn't just C and most criticism of "C/C+" that I
have seen here don't apply to C++ though often the people criticizing
seem to assume so. Saying "C/C++" is a bit like saying Pascal/Ada."

Similarly, I find it hard to take criticism of the form "C++ is no good
because it doesn't completely conform to my principle #3" seriously.
"Principles" should be backed with significant and relevant experience
as well as logic before deserving that title.

Note that there is a tendency to declare any feature that "my" language
doesn't have but "yours" do "unnecessary, dangerous, and confusing" and
conversely any feature that "my" language has and "your" language doesn't
have "essential." Those arguments I also find hard to take serious.

If you are happy with your current language or feel that some language
different from C++ is more to your taste, that's fine with me of course.
There is no reason to believe that any language is the best choice for
everybody and for every application and - like all other languages -
C++ isn't perfect. However, if you want an accurate opinion of C++ rather
than ammunition for some kind of rwar please get some accurate information.

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!asuvax!ennews!enuxha.eas.a]

In article <1992Apr17.211751.24319@aero.org> jordan@aero.org (Larry M. Jordan) 
writes:
>I think you are describing invoking an overridden or redefined method.
>(Please correct me if I've misunderstood.)
>The redefined method must be qualified with the class name, or one gets
>the redefining method.  Has Eiffel changed? I thought renaming was 
>done in the INHERIT clause (by the inheriting class, not the defining class). 
  
	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.  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.

Really it seems as if people aren't worrying about defining the semantics
behind inheritance and simply patching their languages as problems crop
up.  IMO, that's what C++ did with the name visibility problem described
above and it's really a horrible solution.  Some might call this the
evolutionary approach to language design, but it looks more like patching
to me.  Eiffel appears to be an excellent example of design by patching.

>Does Ada "violate information hiding...", since a name can "propogate out 
>of a [package] with more than one meaning"?   

Ada has overloading, Eiffel doesn't.  Naming in Ada is not simply a name,
but also a profile or class of object (type, constant, ...).  Ada never
requires you to know how a package is implemented in order to use it.  If
a package B is offering a something that is actually implemented in some
package A, that relationship is transparent to the user of package B.
--
Harry Koehnemann
koehnema@enuxha.eas.asu.edu

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[Richard Bielak]

In article <1992Apr17.170925.1406@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.e
du (Harry Koehnemann) writes:

[...]

>It seems that the real problem is that no one has done a real good job
>completely defining the semantics of inheritance.  Eiffel didn't get this
>correct in its early versions either and the last Eiffel compiler (they
>have new versions almost bi-annually) I used completely fell apart when
>multiple inheritance was brought into the picture (internal compiler
>errors when renaming with multiple inheritance).
>--
>Harry Koehnemann
>koehnema@enuxha.eas.asu.edu

I've used ISE's Eiffel 2.3 compiler. The problem you describe is with
_repeated_ inheritance, not multiple inheritance. 

The semantics of inheritance are defined very precisely in Eiffel
(see "Eiffel: The Language" by Betrand Meyer), however they are
difficult to implement.

When I discussed this with B. Meyer, he said that the main reasons 
ISE Eiffel 2.3 compiler has these bugs, is because the compiler was 
written in C :-).

Eiffel 3.0, due out this year, was re-written in Eiffel, so repeated
inheritance should work properly.


...richie




-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *

Re: Ada vs. C++ Paper (was Re: Why ADA?)

[Dan Olson]

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)