In <3p15q6$th@tools.near.net> barmar@nic.near.net (Barry Margolin) writes:

>In article <hamilton-1205951112080001@slip-35.io.com> hamilton@io.com (Jim Hamilton) writes:
>>There's a problem with an "inherited::" keyword and multiple inheritance.

>So simply disallow it in that case?  The intuitive notion of
>"inherited::XXX" is that it refers to what "XXX" would refer to if there
>were no definition of it in the local scope.  When XXX is inherited from
>two bases, such a reference is also ambiguous and disallowed, so the same
>would go for inherited::XXX.

The problem is no worse than what happens when, for instance, two functions
of the same name are inherited from two different base classes. Yes, it's
occasionally ambiguous. So just add an explicit scope override to one of the
base classes in that (very rare) situation. I am well and truly mystified
(and annoyed) by the the fact that the C++ committee didn't add this concept
to the language. IMHO, their proposed "alternative" solution (local
typedefs) is unreliable and error-prone (what happens if you forget to
redefine the typedef at some point in your hierarchy of classes?), not to
mention non-intuitive. Furthermore, to use that "solution" consistently
requires a LOT of local typedefs, every one of which is a good opportunity
to make a mistake. This process is definitely NOT a good substitute for
something as direct and simple as the 'inherited::' keyword or its ilk.

Derek Riippa Foster
--
deef@teleport.com  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81)

Hear, hear!
========================================================================
David Cole
Sr. Software Engineer
Arcland Inc.
dcole@arcland.com

In article <sdk-0305950904220001@nhmbma3.humb.nt.com>, sdk@cci.com
(Stephen Knight) wrote:

> In article <3nggfn$sk3@stellar.comnet.com>, "Brian T. Hill"
> <bhil@strata3d.com> wrote:
>
> > xqp@cix.compulink.co.uk ("Martin Jenkins") wrote:
> >
> > >> I've come across the following syntax in some mac code,
> > >> both metroworks and mac app:
> >
> > >> cName::cName()
> > >> {
> > >> .
> > >> .
> > >> .
> > >> inherited::f();
> > >> }
> >

> Originally, Apple's MPW C++ compiler was modified to allow "handle" based
> objects (pointer to a pointer) so that memory could be shuffled around.
> Among the changes necessary to support this, their compiler folks also
> created the "inherited" keyword.  It's not part of the "standard"
> definition, altho Metrowerks supports it also (note:  I've found some C++
> compilers that don't support the "typedef" solution correctly.  they've
> got a scoping problem).
>
> >
> > Can we expect to see this in other C++ implementations?  I personally
> > prefer the compiler to define the keyword.  If the programmer defines
> > it, there can be no guarantee that it actually refers to the superclass.
>
> I wouldn't expect it to appear in other implementations.  Welcome to
> "standards".
>
> steve knight
> northern telecom

There's a problem with an "inherited::" keyword and multiple inheritance.

class A {
   virtual foo();
};

class B {
   virtual foo();
};

class DerivedFromAandB : public A, public B {
   virtual foo();
};

DerivedFromAandB::foo()
{
   inherited::foo();    // which base's foo is called?
}

A typedef in DerivedFromAandB would explicitly solve this, but a keyword would
have a pretty tough time.

--
--

JFH

When in doubt, mumble.

>>>>> Jim Hamilton <hamilton@io.com> writes:

> There's a problem with an "inherited::" keyword and multiple inheritance.

> class A {
>    virtual foo();
> };

> class B {
>    virtual foo();
> };

> class DerivedFromAandB : public A, public B {
>    virtual foo();
> };

> DerivedFromAandB::foo()
> {
>    inherited::foo();    // which base's foo is called?
> }

> A typedef in DerivedFromAandB would explicitly solve this, but a keyword
> would have a pretty tough time.

So it's ambiguous.  What's the problem?

Jason

In article <hamilton-1205951112080001@slip-35.io.com> hamilton@io.com (Jim Hamilton) writes:
>There's a problem with an "inherited::" keyword and multiple inheritance.

So simply disallow it in that case?  The intuitive notion of
"inherited::XXX" is that it refers to what "XXX" would refer to if there
were no definition of it in the local scope.  When XXX is inherited from
two bases, such a reference is also ambiguous and disallowed, so the same
would go for inherited::XXX.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@bbnplanet.com

In article <hamilton-1205951112080001@slip-35.io.com>, hamilton@io.com
(Jim Hamilton) wrote:

< There's a problem with an "inherited::" keyword and multiple inheritance.
<
< class A {
<    virtual foo();
< };
<
< class B {
<    virtual foo();
< };
<
< class DerivedFromAandB : public A, public B {
<    virtual foo();
< };
<
< DerivedFromAandB::foo()
< {
<    inherited::foo();    // which base's foo is called?
< }
<
< A typedef in DerivedFromAandB would explicitly solve this, but a keyword would
< have a pretty tough time.
<
< --
< --
<
< JFH

The problem with the typedef is that you can easily set it to the wrong
inherited base class and not get any warning from the compiler.  Also,
what if you've got a foo in one inherited base class and a bar in
another?  You need two typedefs.

With the built-in keyword there are two types of inherited references:
Ambiguous and non-ambiguous.  If you use the inherited keyword in a
non-ambiguous way then the compiler generates the appropriate function
call and everyone is happy.  If you try to use it in an ambiguous way then
it's a compile-time error.  The example you gave above is an ambiguous use
that the compiler simply can't evaluate.

____________________________________________________________________
Brian  Stern  {:-{)}                          BrianS@pbcomputing.com
Toolbox commando and Menu bard.             Will FlushCache for Cash

In article <3nggfn$sk3@stellar.comnet.com>, "Brian T. Hill"
<bhil@strata3d.com> wrote:

> xqp@cix.compulink.co.uk ("Martin Jenkins") wrote:
>
> >> I've come across the following syntax in some mac code,
> >> both metroworks and mac app:
>
> >> cName::cName()
> >> {
> >> .
> >> .
> >> .
> >> inherited::f();
> >> }
>
> >> cName is a derived class,
> >> "inherited is not a class name anywhere,
> >> (I searched the entire OS),
> >> and f is a function of the base class.
>
> >> I assume that this syntax will find the function f
> >> somewhere in the class hierarchy, howver I cannot find any
> >> reference to this syntax anywhere.
>
> >> Is this something new or some mac extension, or what ?
>
> >Look at p205 of the 2nd edition of Stroustrup. In the index as
> >"inherited::".
>
> I've come across this too.  I've read Stroustrup's suggestion and I
> understand what it means when I see it.  But when did it become a part
> of the language per se?  Stroustrup suggests using a typedef to define
> the keyword, yet Metrowerks seems to use it without the typedef.

Originally, Apple's MPW C++ compiler was modified to allow "handle" based
objects (pointer to a pointer) so that memory could be shuffled around.
Among the changes necessary to support this, their compiler folks also
created the "inherited" keyword.  It's not part of the "standard"
definition, altho Metrowerks supports it also (note:  I've found some C++
compilers that don't support the "typedef" solution correctly.  they've
got a scoping problem).

>
> Can we expect to see this in other C++ implementations?  I personally
> prefer the compiler to define the keyword.  If the programmer defines
> it, there can be no guarantee that it actually refers to the superclass.

I wouldn't expect it to appear in other implementations.  Welcome to
"standards".

steve knight
northern telecom

xqp@cix.compulink.co.uk ("Martin Jenkins") wrote:

>> I've come across the following syntax in some mac code,
>> both metroworks and mac app:

>> cName::cName()
>> {
>> .
>> .
>> .
>> inherited::f();
>> }

>> cName is a derived class,
>> "inherited is not a class name anywhere,
>> (I searched the entire OS),
>> and f is a function of the base class.

>> I assume that this syntax will find the function f
>> somewhere in the class hierarchy, howver I cannot find any
>> reference to this syntax anywhere.

>> Is this something new or some mac extension, or what ?

>Look at p205 of the 2nd edition of Stroustrup. In the index as
>"inherited::".

I've come across this too.  I've read Stroustrup's suggestion and I
understand what it means when I see it.  But when did it become a part
of the language per se?  Stroustrup suggests using a typedef to define
the keyword, yet Metrowerks seems to use it without the typedef.

Can we expect to see this in other C++ implementations?  I personally
prefer the compiler to define the keyword.  If the programmer defines
it, there can be no guarantee that it actually refers to the superclass.
---------------------------
Brian T. Hill
bhil@strata3d.com
http://park.uvsc.edu/~bhil/