Topic: inherited


Author: Marc Sherman <msherman@mag1.magmacom.com>
Date: 1996/10/03
Raw View
>>>>>> "Manfred" == Manfred Morgner <100116.1154@compuserve.com> writes:
>
> Manfred> Why is the "inherited" keyword not used in C++?

In article <ufenjjmo6x.fsf@zen.microlise.co.uk>,
Andrew Gierth  <andrewg@microlise.co.uk> wrote:
>The reason is very simple: it's not necessary to make it part of the
>language, since it can be implemented trivially using existing language
>mechanisms:
[typical typedef solution snipped]

One problem with this solution is that it breaks down in the case of
multiple inheritance.  If I have two classes A and B which I'm multiply
inheriting from, I don't want to have to specify inheritedA:: and
inheritedB:: to select their members -- I want an inherited:: keyword
that uses the information the compiler already has to select the
correct parent and gives a compile error if it's ambiguous.

A hack to get this effect is to move the multiple inheirtance into
an intermediary class:

class A { public: void foo(); void bar(); };
class B { public: void baz(); void bar(); };
class InheritedABhack: public A, public B {};
class C: public InheritedABhack
   {typedef InheritedABhack inherited; void bar() };

Now, C's members can use inherited as expected:

C::bar() {
   inherited::foo(); // calls A::foo
   inherited::baz(); // calls B::baz
   inherited::bar(); // error: ambiguous
};

However, if A or B have anything but default constructors, things
get more complex -- I have to implement constructors in
InheritedABhack to pass the constructor parameters from C to A and
B as appropriate.  This certainly introduces more support hassles,
and may also introduce inefficiency in C's construction depending
on the optimizations the compiler can make.


--
 Marc Sherman |  "What? Rhesus Peasus? | work mailto:marcsh@corel.ca
   CorelDRAW! | Latin. Must be Latin." | personal mailto:msherman@magmacom.com
for Macintosh |  - Edward Ka-Spel, LPD | http://www2.magmacom.com/~msherman/
---
[ 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
]





Author: "Donley R. P'Simer" <donley@mindspring.com>
Date: 1996/10/04
Raw View
Marc Sherman wrote:
> One problem with this solution is that it breaks down in the case of
> multiple inheritance.  If I have two classes A and B which I'm multiply
> inheriting from, I don't want to have to specify inheritedA:: and
> inheritedB:: to select their members -- I want an inherited:: keyword
> that uses the information the compiler already has to select the
> correct parent and gives a compile error if it's ambiguous.

In other words, you want a keyword that will allow class designers
and compilers to make decisions you should make yourself. You have
pointed out an excellent argument *against* adding such a keyword.
What is the meaning of "inherited" when you're using multiple
inheritance? It really makes no sense in this case.

> A hack to get this effect is to move the multiple inheirtance into
> an intermediary class:
>
> class A { public: void foo(); void bar(); };
> class B { public: void baz(); void bar(); };
> class InheritedABhack: public A, public B {};
> class C: public InheritedABhack
>    {typedef InheritedABhack inherited; void bar() };
>
> Now, C's members can use inherited as expected:
>
> C::bar() {
>    inherited::foo(); // calls A::foo
>    inherited::baz(); // calls B::baz
>    inherited::bar(); // error: ambiguous
> };

Yes, its a hack. Look at what happens if class B didn't implement
bar() in version 1.0. The last line isn't an error. Now you get a
brand-spanking-new class B, install it, recompile your code, and
(boom!) you're code is broken. Why should such an error prone
"feature" be added to the language?

IMNSHO, there need be only one way to resolve scope in C++. We have
a more powerfull solution already. There's no need to add a redundant
keyword to the language. "If it ain't broke, don't fix it."

 Donley
---
[ 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
]





Author: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Date: 1996/10/07
Raw View
In article <32551B17.4A2E@mindspring.com> "Donley R. P'Simer"
<donley@mindspring.com> writes:

|> Marc Sherman wrote:
|> > One problem with this solution is that it breaks down in the case of
|> > multiple inheritance.  If I have two classes A and B which I'm multiply
|> > inheriting from, I don't want to have to specify inheritedA:: and
|> > inheritedB:: to select their members -- I want an inherited:: keyword
|> > that uses the information the compiler already has to select the
|> > correct parent and gives a compile error if it's ambiguous.

|> In other words, you want a keyword that will allow class designers
|> and compilers to make decisions you should make yourself. You have
|> pointed out an excellent argument *against* adding such a keyword.
|> What is the meaning of "inherited" when you're using multiple
|> inheritance? It really makes no sense in this case.

What is the sense in calling a function of a base class in this case?
The new keyword would have presumably the same meaning.

|> > A hack to get this effect is to move the multiple inheirtance into
|> > an intermediary class:
|> >
|> > class A { public: void foo(); void bar(); };
|> > class B { public: void baz(); void bar(); };
|> > class InheritedABhack: public A, public B {};
|> > class C: public InheritedABhack
|> >    {typedef InheritedABhack inherited; void bar() };
|> >
|> > Now, C's members can use inherited as expected:
|> >
|> > C::bar() {
|> >    inherited::foo(); // calls A::foo
|> >    inherited::baz(); // calls B::baz
|> >    inherited::bar(); // error: ambiguous
|> > };

|> Yes, its a hack. Look at what happens if class B didn't implement
|> bar() in version 1.0. The last line isn't an error. Now you get a
|> brand-spanking-new class B, install it, recompile your code, and
|> (boom!) you're code is broken. Why should such an error prone
|> "feature" be added to the language?

It's already there.  Suppose that class C didn't have a member C::bar,
but one of its other members called bar (without a scope qualifier).

This just happens to be the way C++ works.  I wouldn't even use the
words "error prone" for this behavior.  On the contrary, it prevents
errors by making them apparent in the compiler.  (Take your scenario,
and suppose that the new B::bar must be called, as well as the old
A::bar.  If I have written "B::bar()"" in my code, it will slip through
unnoticed.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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                             ]





Author: "Manfred Morgner" <100116.1154@compuserve.com>
Date: 1996/09/30
Raw View
Hallo,

if here is the forum, where programmers talk about C++, I have a question
to all people who are involved in language developing.

Why is the "inherited" keyword not used in C++?

If I should make my classes universal, I need to create a mass of MACROS,
Headers and so on. But, if I can write

void C::M(void) // C id derived from B
  {
  inherited M(void); // to call B::M(void)
  }

later I can derive C from D and "inherited M(void)" calls "D::M(void)"

Is this a problem of the compiler or a problem of the language
implementation. I think, this solution is strongly object oriented and I
missed it more than ones.
--
Manfred Morgner
100116.1154@compuserve.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
]





Author: Andrew Gierth <andrewg@microlise.co.uk>
Date: 1996/10/01
Raw View
>>>>> "Manfred" == Manfred Morgner <100116.1154@compuserve.com> writes:

 Manfred> Hallo, if here is the forum, where programmers talk about
 Manfred> C++, I have a question to all people who are involved in
 Manfred> language developing.

 Manfred> Why is the "inherited" keyword not used in C++?

This issue is discussed in Stroustrup's "The Design and Evolution of C++",
which should always be consulted prior to asking a question of this kind.

The reason is very simple: it's not necessary to make it part of the
language, since it can be implemented trivially using existing language
mechanisms:

class A : public B
{
    typedef B inherited;
    ...
};

void A::foo()
{
    inherited::foo();
}

Note that although B is specified twice in this method, the two occurrences
are very close together.

At least one major class library uses this convention.

--
Andrew Gierth (andrewg@microlise.co.uk)

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam


[ 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                             ]





Author: Rune Huseby <rune.huseby@gpi.telemax.no>
Date: 1996/10/01
Raw View
Manfred Morgner wrote:
>
> Hallo,
>
> if here is the forum, where programmers talk about C++, I have a question
> to all people who are involved in language developing.
>
> Why is the "inherited" keyword not used in C++?
>
> If I should make my classes universal, I need to create a mass of MACROS,
> Headers and so on. But, if I can write
>
> void C::M(void) // C id derived from B
>   {
>   inherited M(void); // to call B::M(void)
>   }
>
> later I can derive C from D and "inherited M(void)" calls "D::M(void)"
>
> Is this a problem of the compiler or a problem of the language
> implementation. I think, this solution is strongly object oriented and I
> missed it more than ones.

Because you can say this in your definition of the class C:

class C : public B
{
protected:// I use protected because outsiders need not now the base
class,
          // but you might want to say i.e. inherited::inherited::foo(x)
   typedef B inherited;
//.....
   void M(void);
};

void C::M(void) // C id derived from B
{
   inherited::M(); // to call B::M(void)
}

And which base class should a keyword 'inherited' refer to
with multiple inheritance?


--
Rune Huseby

I speak for me!


[ 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                             ]





Author: Osteometer Meditech <meditech@inet.uni-c.dk>
Date: 1996/10/01
Raw View
Manfred Morgner wrote:
>
> Hallo,
>
> if here is the forum, where programmers talk about C++, I have a question
> to all people who are involved in language developing.
>
> Why is the "inherited" keyword not used in C++?
>
> If I should make my classes universal, I need to create a mass of MACROS,
> Headers and so on. But, if I can write
>
> void C::M(void) // C id derived from B
>   {
>   inherited M(void); // to call B::M(void)
>   }
>
> later I can derive C from D and "inherited M(void)" calls "D::M(void)"
>
> Is this a problem of the compiler or a problem of the language
> implementation. I think, this solution is strongly object oriented and I
> missed it more than ones.
> --
> Manfred Morgner
> 100116.1154@compuserve.com...

This is easily achievable by creating a typedef in the base class definition. A good discussion on why this
was not in the standard and how to do it is in "Design and Evolution of C++" by Bjarne Stroustrup. This book
is an absolute _must_ anyway so buy it now :-).

--
Steven Kefford
Osteometer MediTech
Gleupvej 2, DK-2620 R   dovre, Denmark
Tel. (+45) 44 92 42 00:     e-mail meditech@inet.uni-c.dk
---
[ 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
]





Author: "Donley R. P'Simer" <donley@mindspring.com>
Date: 1996/10/01
Raw View
Manfred Morgner wrote:
>
> Why is the "inherited" keyword not used in C++?
>
> If I should make my classes universal, I need to create a
> mass of MACROS, Headers and so on. But, if I can write
>
> void C::M(void) // C id derived from B
>   {
>   inherited M(void); // to call B::M(void)
>   }
>
> later I can derive C from D and "inherited M(void)" calls "D::M(void)"
>
The main reason I can see for not including this mechanism is that
the scope resolution operator is more powerfull and there is no
reason to include more that one way of doing the same thing. Given
three classes: C derived from B derived from A and a virtual member
M(), C's implementation of M() can call A's version of M() bypassing
B's version. You cannot do that with this "inherited" keyword.
Also, I doubt that the situation you describe happens often enough
to make it a compelling reason to add a keyword. Besides, if you're
going to redesign your class hierarchy, you should expect to incur
some substantial recoding work.

 Donley
---
[ 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
]





Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1996/10/02
Raw View
Manfred Morgner wrote:
> void C::M(void) // C id derived from B
>   {
>   inherited M(void); // to call B::M(void)
    ^^^^^^^^^^^ I assume inherited::M here
>   }
>
> later I can derive C from D and "inherited M(void)" calls "D::M(void)"

This is the third time this issue is raised in comp.std.c++ since I
follow the newsgroup (say during less than one year).

Macintosh compilers all have the inherited keyword (of course that's
an option; you can desactivate it in order to write portables
programs).

We can live without it since a typedef do the trick; I think the
introduction of a new keyword is not justified by the little gain.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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
]