>> Why not just use a typedef?  The only disadvantages compared to a new
>> keyword are the lack of a standard (i.e., what typedef name to use) and
>> the possibility that clients will unwittingly 'inherit' from a class
>> they didn't want to:
>>
>>         struct a { typedef inherited a; void foo(); };
>>         struct b : public a { void foo(); };
>>         struct c : public b { void foo() { inherited::foo(); } };
>>
>> I suppose I just made a decent argument in favour of a keyword :-)

How about making the typedef private, so it cannot be inherited, e.g.
struct a: public base_a { private: typedef base_a inherited ; public: ... }?

   David E. Miller
   david@atl-intl.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Ryzhenkov Ilya wrote:
>
> ALL I WRITE HERE IS JUST IMHO! ;-)
>
> Mike Duigou wrote:
> >
> > The advantage is that if you wanted to insert another class between a and
> > b, then you would not need to change the reference to the previous
> > implemantion of "doit".
>
> This is not advantage! In any case when you insert a class between two others
> in inheritance tree (i don't mean simple ones) you HAVE TO make some changes
> in them both, as overall behavior of the most derived object changes a lot.
>

Not necessarily.  The inherited keyword would typically be used for
those APIs where it is well-defined that you are supposed to call the
base class version of the method at some point in your derived version.

This is extremely common.

Note that every other non-MI language has some version of the inherited
keyword, so your argument that it's not a good concept in a
singly-derived context is pretty unrealistic.

The only substantial argument against the inherited keyword is MI...

>  Btw, consider multiply inheritance and the meaning of "inherited" in that case.
>

Yes, this is the gray area.  I've always thought they could make
inherited represent the first class listed in the base class list.
Agreed, this is fairly arbitrary, but it's better than losing the
convenience of the keyword altogether.  Alternatively, the language
could specify that inherited is meaningless in any class with multiple
bases.  This would be perhaps cleaner in some sense.

I use a macro to define inherited in all my own programming and always
find it tedious to be in an environment which doesn't have that.  I saw
a case just today at work where a change of base class required numerous
code changes, and *none* of these changes would have been necessary if
the inherited keyword had been available and used instead.  This was in
a singly derived context...


-- Paul
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Paul Bossi  <bossi@primenet.com> wrote:
>
>I use a macro to define inherited in all my own programming and always
>find it tedious to be in an environment which doesn't have that.

Using a macro seems dangerous to me, in particular if you have more than
one class with "inherited" in a single translation unit.  The suggestion
by Mike Tiemann (when the keyword "inherited" was rejected) was to use
a typedef:

 struct A { ...... };

 struct B : A {
  typedef A inherited;
  .....
 };

This definition of "inherited" is properly scoped.

The "keyword inherited" proposal presented to the C++ standards committee
did indeed discuss the MI case, suggesting that "inherited" would be
ambiguous (i.e., incorrect).

Dag Bruck
Author of "keyword inherited" proposal

--
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden                                URL:    http://www.dynasim.se



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

( John J.D. Hickin 6V33 BNR ) wrote:
>
> It has probably been mentioned to you before but here goes anyway...
>
> Why not just use a typedef?  The only disadvantages compared to a new
> keyword are the lack of a standard (i.e., what typedef name to use) and
> the possibility that clients will unwittingly 'inherit' from a class
> they didn't want to:
>
>         struct a { typedef inherited a; void foo(); };
>         struct b : public a { void foo(); };
>         struct c : public b { void foo() { inherited::foo(); } };
>
> I suppose I just made a decent argument in favour of a keyword :-)

Um, it's not a huge problem in my own code because as I mentioned I use
a macro (which does a typedef like you mention and in fact some other
unrelated things as well...).  It's still tedious and somewhat error
prone to have my class name on two separate lines, one in the prefix to
the class declaration and the other in the typedef.  I've had cases of
bugs that arose because of these not being in sync, and note that the
compiler won't help you out if you for instance by accident have the
typedef pointing to a base type of what it should be.  Also, using the
typedef precludes declaring the Inherited type public, which I think can
be very useful -- it precludes it because then you get really error
prone, e.g. if you define the type in one class then forget in a derived
class but continue to use the word, problems.

So, yes, I'd prefer that the compiler take care of this trivia for me.


-- Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

ALL I WRITE HERE IS JUST IMHO! ;-)

Mike Duigou wrote:
>
> The advantage is that if you wanted to insert another class between a and
> b, then you would not need to change the reference to the previous
> implemantion of "doit".

This is not advantage! In any case when you insert a class between two others
in inheritance tree (i don't mean simple ones) you HAVE TO make some changes
in them both, as overall behavior of the most derived object changes a lot.

> Additionally, it encourages programming for specialization by
> making the calling of the base member function conceptuallly simpler. Actually this keyword encourages programmer not to plan his inhertiance tree
 well before doing porgramming.

 Are you sure you want to have a macro "inherited", which expands in the name
    of the base class ? This keyword acts exactly this manner ...

 Btw, consider multiply inheritance and the meaning of "inherited" in that case.

--
       Sincerely yours, Ilya
mailto:ilya@spy.isp.nsc.ru
http://spy.isp.nsc.ru
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <199610221638.JAA04708@taumet.eng.sun.com>
clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:

> 1. You can get the functionality with a member typedef which appears
>    lexically near the base-list of the class:

No.  It doesn't work for multiple inheritence.  You need multiple
typedef's as the following:

        class Base1 { public: void foo(); };

        class Base2 { public: void bar(); };

        class Derived : public Base1, public Base2 {
        public:
            typedef Base1 inherited1;   // ugly...
            typedef Base2 inherited2;

            void foo() {
                inherited1::foo();
                ...
            }

            void bar() {
                inherited2::bar();
                ...
            }
        };

> 2. "Inherited" adds new ambiguities in the presence of multiple
> inheritence.

No.  The ambiguity is not new.  It's already in the multiple
inheritence itself.  If inherited::foo() is resolved as if foo()
was not declared in the derived class, no new rule is required
-- it is a natural extension.

        class Base1 { public: void foo(); };

        class Base2 { public: void foo(); };

        class Derived1 : public Base1, public Base2 {
        public:
            void foo() {
                inherited::foo();       // ambiguous.
                ...
            }
        };

        class Derived2 : public Base1, public Base2 {
        public:
            // no foo() in class Derived2.

            void bar() {
                foo();                  // ambiguous, too.
                ...
            }
        };

> On balance, adding "inherited" was judged not to be justified.

I agree, though.

hoshi
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

   I was thinking in the shower this morning that given all that was added
to the C++ language during the standardization process, how is it that the
"inherited" keyword managed to slip through? For those not familiar with
this keyword:

the "inherited" keyword allows you to refer implicitly to the base class of
an object, without needing to know the exact name of that object. It comes
from Apple's object pascal and has been implemented as an extension in
several C++ compilers (Metrowerks and Symantec come to mind). It is
generally used to refer to the "previous" implementation of a virtual
member function which the current member function is overriding. ex.

class a
   {
   virtual int doit( int x, int y );
   }

class b : public a
   {
   virtual int doit( int x, int y );
   }

int b::doit( int x, int y )
{
int result;

result = x * y;

return( result );
}

int b::doit( int x, int y )
{
int result;

result = inherited::doit( x,y ) + 3; // "inherited" refers to "a" in this case
// result = a::doit( x,y ) + 3 without "inherited"

return( result );
}

The advantage is that if you wanted to insert another class between a and
b, then you would not need to change the reference to the previous
implemantion of "doit". The previous implementation of "doit" could be
located anywhere in the inheritance chance and the compiler would figure
out which function you actually meant. The feature promotes better
encapsulation because you don't need to care where the base virtual member
is located. Additionally, it encourages programming for specialization by
making the calling of the base member function conceptuallly simpler.


Mike Duigou
FWB Software LLC.
--
"Me, when I have nothing to say, my lips are sealed." -- Talking Heads


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article ya023180002110962005260001@news.inow.com, mike_duigou@fwb.com (Mike Duigou) writes:
>
>   I was thinking in the shower this morning that given all that was added
>to the C++ language during the standardization process, how is it that the
>"inherited" keyword managed to slip through? For those not familiar with
>this keyword:
>
>the "inherited" keyword allows you to refer implicitly to the base class of
>an object, without needing to know the exact name of that object. ...

That is a frequently-asked question, althought it is not yet in the FAQ
list for this group. It was discussed to death recently in the newsgroup.
Try dejanews if your news server doesn't have the articles. D&E also
has a discussion of "inherited".

1. You can get the functionality with a member typedef which appears
   lexically near the base-list of the class:

 class Derived : public Base {
 public:
  typedef inherited Base;
 ...
 };
If the hierarchy changes, you need to change the base-list; changing
the typedef at the same time is not much of a hardship.

2. "Inherited" adds new ambiguities in the presence of multiple
inheritence.

On balance, adding "inherited" was judged not to be justified.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]