In article <2869770301@hoult.actrix.gen.nz>, Bruce Hoult writes:

>
> joseph@joebloe.maple-shade.nj.us (Joseph "Moof-in'" Hall) writes:
> > ) The C++ ANSI committee considered adding an Inherited keyword,
based on
> > ) Apple's experience with it in Object Pascal and MPW C++.  They
very nearly
> > ) approved it, until someone pointed out at the last moment that
the
> > ) programmer can easily fake it for himself:
> > )
> > ) class myDynamicArray: public LDynamicArray {
> > )    typedef LDynamicArray Inherited;
> > )
> > )    // other stuff...
> > ) }

-Stuff deleted-
> What preprocessor?  That's not using the preprocessor -- it's a
prefectly
> type-safe and properly scoped member of the class.

Its not type-safe and properly scoped in CW.
As declared, its private, which means Inherited can ONLY be used in
members
of myDynamicArray, and not in members of classes derived from it -
which
is exactly what you want - except that CW doesnt treat it as private.
If you derive a class from myDynamicArray, forget to typedef
Inherited,
but use it anyway, you will call the wrong function with no warning.
In fact, CW doesnt seem to enforce private very much at all.

Mark Williams<mark@streetly.demon.co.uk>

Peter Kron (pkron@corona.com) wrote:
: From: jason@cygnus.com (Jason Merrill)
: >  >>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:

: >  !Whether or not it is built into the language, "inherited" still doesn't
: >  !work well for MI, which is one reason for not putting it in the language.
: >
: >  I've never understood this argument.  As I see it,
: >  "inherited" is most useful in MI -- it means "anywhere
: >  but here", so you can write things like
: >
: > [example deleted]
: >
: >  Of course, if the call would be ambiguous without the
: >  definition in the current class, the call with inherited::
: >  is ambiguous.  What's so difficult about that?
: >
: >  Not that I particularly care about this feature...I don't
: >  think I'd ever use it myself.

: To each his own, but I wince whenever I write BaseClass::function()
: within the body of Derived::function(), knowing that <function> is
: unique. I can imagine myself cursing 5 years down the line when
: IntermediateClass::function() is interposed in the hierarchy between
: BaseClass and DerivedClass...and much time is wasted tracking down
: the subtle bug (which wasn't caught by the compiler and escaped to
: the customer site). "typedef BaseClass inherited" doesn't solve this.

: Sure, it's a design failure, but think about how much code is
: currently being ported to WindowsNT which was originally written to
: support real-mode Windows 2.1. Such failures are inevitable.
: ---
: NeXTMail:peter.kron@corona.com
: Corona Design, Inc.
: P.O. Box 51022
: Seattle, WA 98115-1022

I whole heartedly agree.  MI and the "inherited" keyword have nothing do with
one another.  This misconception, I think, is due to a subconscious desire to
have "inherited" somehow make MI ambiguities go away.  As for the so called
typedef solution, it suffers from exactly the same affliction that prompted
the "inherited" keyword proposal.  Ie. that code must be changed in the derived
class when an intermediate class is introduced.  I don't believe this feature
is as trival and unimportant as others have indicated.  The maintainability
of the reams of C++ code developed today are going to be maintained for many
years to come (that's because reuseability is one of the cornerstones of OO and
C++), and class hierarchies are as subject to change as any other element of
the language.  I foresee many subtle bugs being introduced by the lack of
the "inherited" keyword.

I can't see why this proposal has not succeeded.  It is unlikely to break
existing code and it will make class hierarchies resistent to bugs.

Stephen Cipolli
Datascope Corp.

In article <3cgm55$iim@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
[..]
|> I don't understand what your complaint is. You are not required by any
|> language rule to use "inherited". If you want the convenience, you can
|> add the typedef.
[..]
|>
|> Whether or not it is built into the language, "inherited" still doesn't
|> work well for MI, which is one reason for not putting it in the language.
                                  ^^^^^^^^^^^^^^(*)

No, it is the other way round: typedef doesn't work at all for MI.
You can't make a typedef for all baseclasses at once!
That is one reason FOR putting the keyword "inherited" in the language.
"inherited.x" ONLY doesn't work when the X is ambigious (i.e. inherted from
multiple baseclasses).

Disclaimer: IMHO "inherited" is not worth it. It is not necessary.
It would just be a 'nice' thing.
Sorry, but I couldn't let this (*) uncommented.

Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de

In article <1994Dec14.033940.248@corona.com> pkron@corona.com writes:
>
>To each his own, but I wince whenever I write BaseClass::function()
>within the body of Derived::function(), knowing that <function> is
>unique.

 I'd wince too. Then I'd go and try to find out why
my _design_ was faulty requiring me to do this ugly stuff.
It doesn't make sense.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

joseph@joebloe.maple-shade.nj.us (Joseph "Moof-in'" Hall) writes:


>I suppose my comment was a little confusing.
 [ about "typedef base_class inherited;" ]
>What I was trying to say is that
>boilerplate inspires use of the preprocessor to generate boilerplate.  Facing
>the need to consistently add typedefs to 20 or 50 or 100 classes, I would
>probably resort to the preprocessor to do my typing for me.

I don't understand what your complaint is. You are not required by any
language rule to use "inherited". If you want the convenience, you can
add the typedef.

I don't see how a preprocessor macro would relieve you of many
keystrokes anyway. A text editor macro, yes, but that is outside C++.
When you write a class, the amount of extra typing for "inherited"
should not be very noticeable. You might also be able to use it in
a template:
 template <class T, class base> class Foo : public base {
  typedef base inherited;
  ...
 };

Whether or not it is built into the language, "inherited" still doesn't
work well for MI, which is one reason for not putting it in the language.

--
Steve Clamage, stephen.clamage@eng.sun.com

>>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:

> Whether or not it is built into the language, "inherited" still doesn't
> work well for MI, which is one reason for not putting it in the language.

I've never understood this argument.  As I see it, "inherited" is most
useful in MI -- it means "anywhere but here", so you can write things like

struct A {
  void f () { ... };
};

struct B {
  void g () { ... };
};

struct C: public A, public B {
  void f () { ...; inherited::f (); }
  void g () { ...; inherited::g (); }
};

Try doing *that* with a typedef.  Of course, if the call would be ambiguous
without the definition in the current class, the call with inherited:: is
ambiguous.  What's so difficult about that?

Not that I particularly care about this feature...I don't think I'd ever
use it myself.

Jason

From: jason@cygnus.com (Jason Merrill)
>  >>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:

>  !Whether or not it is built into the language, "inherited" still doesn't
>  !work well for MI, which is one reason for not putting it in the language.
>
>  I've never understood this argument.  As I see it,
>  "inherited" is most useful in MI -- it means "anywhere
>  but here", so you can write things like
>
> [example deleted]
>
>  Of course, if the call would be ambiguous without the
>  definition in the current class, the call with inherited::
>  is ambiguous.  What's so difficult about that?
>
>  Not that I particularly care about this feature...I don't
>  think I'd ever use it myself.

To each his own, but I wince whenever I write BaseClass::function()
within the body of Derived::function(), knowing that <function> is
unique. I can imagine myself cursing 5 years down the line when
IntermediateClass::function() is interposed in the hierarchy between
BaseClass and DerivedClass...and much time is wasted tracking down
the subtle bug (which wasn't caught by the compiler and escaped to
the customer site). "typedef BaseClass inherited" doesn't solve this.

Sure, it's a design failure, but think about how much code is
currently being ported to WindowsNT which was originally written to
support real-mode Windows 2.1. Such failures are inevitable.
---
NeXTMail:peter.kron@corona.com
Corona Design, Inc.
P.O. Box 51022
Seattle, WA 98115-1022

In article <2869770301@hoult.actrix.gen.nz> (comp.sys.mac.programmer.codewarrior,comp.std.c++), Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
) joseph@joebloe.maple-shade.nj.us (Joseph "Moof-in'" Hall) writes:
) > ) The C++ ANSI committee considered adding an Inherited keyword, based on
) > ) Apple's experience with it in Object Pascal and MPW C++.  They very nearly
) > ) approved it, until someone pointed out at the last moment that the
) > ) programmer can easily fake it for himself:
) > )
) > ) class myDynamicArray: public LDynamicArray {
) > )    typedef LDynamicArray Inherited;
) > )
) > )    // other stuff...
) > ) }
) >
) > It doesn't really work all that well in my opinion, e.g. in case of
) > multiple inheritance.  If "inherited" were allowed to work with MI (and
) > simply report ambiguous uses as an error) it would be a powerful
) > construct that would be difficult to reproduce with existing C++
) > features.
)
) Agreed.
)
) > Also, the above bothers me a little.  After one gets over the familiar
) > "gee, it's neat that you can do that with ordinary C++" reaction, one gets
) > the equally familiar "great, another piece of boilerplate to add to all
) > of my classes" reaction.
)
) Agreed.
)
) > Or, "swell--why are there still all these
) > reasons to use the preprocessor when the principal designer of C++ has
) > gone on for years and years about wanting to abolish it?"
)
) What preprocessor?  That's not using the preprocessor -- it's a prefectly
) type-safe and properly scoped member of the class.

I suppose my comment was a little confusing.  What I was trying to say is that
boilerplate inspires use of the preprocessor to generate boilerplate.  Facing
the need to consistently add typedefs to 20 or 50 or 100 classes, I would
probably resort to the preprocessor to do my typing for me.

The mandate to "codify existing practice" in standardizing C should
not, in my opinion, be construed to suggest that the C++ committee
should codify neat tricks that work almost as well as properly implemented
language features.  To wit ....

This isn't to say that the committee hasn't done a lot of good work
otherwise.

=============== O Fortuna, velut Luna, statu variabilis ===============
uunet!joebloe!joseph   (602) 732-2549 day   joseph%joebloe@uunet.uu.net
1400 N Alma School                #163               Chandler, AZ 85224
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
           Be hip!  Support comp.sys.mac.programmer.moof!

In article <2869478602@hoult.actrix.gen.nz> (comp.sys.mac.programmer.codewarrior), Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
) The C++ ANSI committee considered adding an Inherited keyword, based on
) Apple's experience with it in Object Pascal and MPW C++.  They very nearly
) approved it, until someone pointed out at the last moment that the
) programmer can easily fake it for himself:
)
) class myDynamicArray: public LDynamicArray {
)    typedef LDynamicArray Inherited;
)
)    // other stuff...
) }

It doesn't really work all that well in my opinion, e.g. in case of
multiple inheritance.  If "inherited" were allowed to work with MI (and
simply report ambiguous uses as an error) it would be a powerful
construct that would be difficult to reproduce with existing C++
features.

Also, the above bothers me a little.  After one gets over the familiar
"gee, it's neat that you can do that with ordinary C++" reaction, one gets
the equally familiar "great, another piece of boilerplate to add to all
of my classes" reaction.  Or, "swell--why are there still all these
reasons to use the preprocessor when the principal designer of C++ has
gone on for years and years about wanting to abolish it?"

Anyway, the committee decided after due deliberation to blow it off, and
Stroustrup even cites it as an example of a perfectly reasonable feature that
they had perfectly reasonable committee-like reasons not to adopt.  Oh, well.
Not much point arguing any more.

Followups to comp.std.c++, if you please.

=============== O Fortuna, velut Luna, statu variabilis ===============
uunet!joebloe!joseph   (602) 732-2549 day   joseph%joebloe@uunet.uu.net
1400 N Alma School                #163               Chandler, AZ 85224
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
           Be hip!  Support comp.sys.mac.programmer.moof!

) class myDynamicArray: public LDynamicArray {
)    typedef LDynamicArray Inherited;
)
)    // other stuff...
) }

> It doesn't really work all that well in my opinion, e.g. in case of
> multiple inheritance.  If "inherited" were allowed to work with MI (and
> simply report ambiguous uses as an error) it would be a powerful
> construct that would be difficult to reproduce with existing C++
> features.

Yes, but we argued that the typedef is typically so close to the list
of base classes that you would rarely forget to change both.

> Or, "swell--why are there still all these reasons to use the
> preprocessor when the principal designer of C++ has gone on for years
> and years about wanting to abolish it?"

Please not that it uses a typedef, which is not part of the
preprocessor and obeys scope rules.  It just wouldn't work with a
#define.

     -- Dag Bruck

joseph@joebloe.maple-shade.nj.us (Joseph "Moof-in'" Hall) writes:
> ) The C++ ANSI committee considered adding an Inherited keyword, based on
> ) Apple's experience with it in Object Pascal and MPW C++.  They very nearly
> ) approved it, until someone pointed out at the last moment that the
> ) programmer can easily fake it for himself:
> )
> ) class myDynamicArray: public LDynamicArray {
> )    typedef LDynamicArray Inherited;
> )
> )    // other stuff...
> ) }
>
> It doesn't really work all that well in my opinion, e.g. in case of
> multiple inheritance.  If "inherited" were allowed to work with MI (and
> simply report ambiguous uses as an error) it would be a powerful
> construct that would be difficult to reproduce with existing C++
> features.

Agreed.


> Also, the above bothers me a little.  After one gets over the familiar
> "gee, it's neat that you can do that with ordinary C++" reaction, one gets
> the equally familiar "great, another piece of boilerplate to add to all
> of my classes" reaction.

Agreed.


> Or, "swell--why are there still all these
> reasons to use the preprocessor when the principal designer of C++ has
> gone on for years and years about wanting to abolish it?"

What preprocessor?  That's not using the preprocessor -- it's a prefectly
type-safe and properly scoped member of the class.

-- Bruce