Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!mcnc!decvax!decwrl!pyramid!prls!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c++
Subject: Re: C++ enhancements
Message-ID: <2786@mmintl.UUCP>
Date: 25 Mar 88 17:49:56 GMT
References: <2781@mmintl.UUCP> <7757@alice.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Ashton-Tate Corporation, East Hartford Development Center
Lines: 88

In article <7757@alice.UUCP> bs@alice.UUCP writes:
>franka @ Ashton-Tate Corporation, East Hartford Development Center writes:
> > Following are some suggestions for improvements to C++.
>
>C++ is in widespread use.  Much of this use is in non-research environments;
>there are more than four independent organizations producing C++ compilers
>and many more building tools and libraries.
>
>The implication is that we must be quite restrained when it comes to
>``improving'' the language or else we will fracture it into several
>incompatible dialects.

This is a good point.  On the other hand, it is never going to get any
easier to add features to the language.  Moderation is fine, but some sort
of procedure for adding relatively small increments to the language should
be in place.

> > Add a new keyword "leaf" to the language.  This is applied to a (virtual)
> > function declaration to indicate that the function is not redefined in any
> > subclass of the current class.
>
> and second because the optimization already can be and is done in
>many cases. Consider:
>
>	class B { public: virtual f(); };
>	class D : public B { public: f(); };
>
>	f(D a, D* p) {
>		a.f();	// generates a non-virtual call to D::f()

It is my impression that pointers and references to objects are
significantly more common than actual instances; thus this optimization
occurs fairly rarely in practice.  I have no hard evidence on this point.

Global optimization is another possible approach to this sort of thing; it
is clearly superior if available.
	
> Is there a real need for disallowing derivation in some cases?

A good question.  I can well imagine that a methodology might want such a
prohibition, but I don't know of any methodologies which use inheritance
which do.

There are classes in Smalltalk which one does not want to subclass, because
of implementation details.  (For example, Point has lots of methods which
build new points using "@"; if one wishes to subclass it, one will have to
replace lots of methods.  A more extreme example is SmallInteger.)  However,
nothing like this is obviously applicable to C++.


> > Why not let the result of applying the & operator to a reference variable
> > be an lvalue?
>
>Would &a++ and ++&a be allowed? &a[2] ? (Quick: where do we need
>parentheses?).

It had better be (&a)++ and (&a)[2].

>Is ``*&a'' always the same as ``a''?

Yes.

>Actually, this proposal is probably the most sensible one I have seen for
>allowing the value of a reference to change. However, the bottom line is:
>What do you get by extending the language? In this case I think the answer
>is
>	(1) a minor notational convenience

I can't really argue with this.  This was perhaps the weakest of my
suggestions.

>	(2) larger manuals and compilers

Not, I think, by very much.

> > Has anything been done yet about the ambiguity of prefix and postfix
> > operators when overloading "++" and "--"?
>
>I am still unconvinced that this extension would add anything significant to
>C++.

But here, we are talking about simplifying the manuals and user
explanations.  Why can't I do the same thing with a defined operator that I
can do with the built-in operators?
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108