"base" keyword
Electric Ninja
base class, similar to the "this" keyword to the class itself. It would
sure simplify MFC development. But would that cause problems in situations
with multiple inheritance (I've never had to work with it before)?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Ron Natalie
"Electric Ninja" <no...@jose.dude> wrote in message news:8E3O9.15503$%3.43...@twister.neo.rr.com...
> It would be nice if there were a "base" keyword to refer to the previous
> base class, similar to the "this" keyword to the class itself. It would
> sure simplify MFC development. But would that cause problems in situations
> with multiple inheritance (I've never had to work with it before)?
What happens if there is more than one base class?
Philippe Mori
class Derived : public Base {
private:
typedef Base base; // private to restrict the uses from
outside...
};
If you have more than one class, you would typically do a typedef for the
primary class or used an alternate typedef:
class D2 : public BaseWnd, public BaseAction {
typedef BaseWnd base;
typedef BaseAction base_action;
};
Where I was working we used inherited instead of base... but the effect is
the same. I sometime read that it is because of the possibility of using a
typedef that it was not added to the language.
Such a typedef is really usefull for UI code since we may want to modify the
classes hierarchy as we may want to reuse part of the functionality for a
similar windows or dialog... And the typedef could be used in a lot of place
including some tables like ATL, MFC and OWL do have...
Hyman Rosen
> What happens if there is more than one base class?
That is when the keyword becomes most useful. If a name is
defined in exactly one base class, then base::name refers
to that name, otherwise the compiler generates an error.
Philippe Mori
>
> That is when the keyword becomes most useful. If a name is
> defined in exactly one base class, then base::name refers
> to that name, otherwise the compiler generates an error.
>
I never though about it... but in fact this is one advantage over using a
typedef in that case...
One way to achieve similar result with current standard would be:
// Original bases (B1 and B2)
class B1 {
public:
void f() {}
void g() {}
};
class B2 {
public:
void f() {}
void h() {}
};
// Intermediate class for the typedef
class Bi : public B1, public B2 {
protected:
typedef B1 base1;
typedef B2 base2;
};
class B : public Bi {
typedef Bi base;
public:
void test() {
// base::f(); // ambiguity --- won't compile!
base1::f();
base2::f();
base::g(); // here we can uses base --- no ambiguity
base::h();
}
};
int main() {
B b;
b.test();
return 0;
}
It a bit annoying to do it each time... If we have a pattern that come
often, we may be able to uses a template for the intermediate class. For
example, the following template could be used if we have 2 bases with a
single argument constructor in each one:
template <typename B1, typename B2, typename T1, typename T2>
class join_bases {
public:
join_bases(T1 t1, T2 t2) : B1(t1), B2(t2) { }
protected:
// We may remove these 2 typedef because they are a bit meaningless.
// We can also move them in derived class where we could select
// appropriate name for each typedef.
typedef typename B1 base1;
typedef typename B2 base2;
typedef typename join_bases<B1, B2, T1, T2> base;
};
Stephen Howe
> base class, similar to the "this" keyword to the class itself. It would
> sure simplify MFC development. But would that cause problems in
situations
> with multiple inheritance (I've never had to work with it before)?
It is not needed. See "Design and Evolution of C++" by Bjarne Stroustrup and
look at proposed "inherited" keyword.
Stephen Howe
Allan W
> It would be nice if there were a "base" keyword to refer to the previous
> base class, similar to the "this" keyword to the class itself. It would
> sure simplify MFC development. But would that cause problems in situations
> with multiple inheritance (I've never had to work with it before)?
See Design & Evolution of C++.
The usual answer is that yes, Multiple Inheritance makes the implementation
of "base" (or "parent") impossible -- and there's no need to find an
"almost" solution, because we already have an easy workaround.
struct A { ... };
struct B : public A {
typedef A parent; // or typedef A base;
...
};
Same technique could be used in MI classes, where the author gets to
pick which one of the base classes is the most natural parent. Or the
author could avoid that choice as well:
struct C : public D, public E, public F {
typedef D base1;
typedef E base2;
typedef F base3;
...
};
Nikolaos D. Bougalis
"Electric Ninja" <no...@jose.dude> wrote in message
news:8E3O9.15503$%3.43...@twister.neo.rr.com...
> base class, similar to the "this" keyword to the class itself. It would
> sure simplify MFC development. But would that cause problems in
situations
> with multiple inheritance (I've never had to work with it before)?
The .NET version of the C++ compiler (13.00 for those keeping count) has
the keyword __super... From the documentation:
"The __super keyword allows you to explicitly state that you are calling a
base-class implementation for a function that you are overriding. All
accessible base-class methods are considered during the overload resolution
phase, and the function that provides the best match is the one that is
called."
-n
KIM Seungbeom
>
> The .NET version of the C++ compiler (13.00 for those keeping count) has
> the keyword __super... From the documentation:
>
> "The __super keyword allows you to explicitly state that you are calling a
> base-class implementation for a function that you are overriding. All
> accessible base-class methods are considered during the overload resolution
> phase, and the function that provides the best match is the one that is
> called."
Then it means that you cannot know which type __super in itself is
and that it is meaningful only in the contexts of qualification.
struct A { void a(); void common(); };
struct B { void b(); void common(); };
struct X : A, B {
void x() {
__super::a(); // __super refers to A here
__super::b(); // __super refers to B here
__super::common(); // unable to resolve
typeid(__super); // unable to resolve
}
}
I'm not sure whether it could be useful.
--
KIM Seungbeom <musi...@bawi.org>
Philippe Mori
>
> Then it means that you cannot know which type __super in itself is
> and that it is meaningful only in the contexts of qualification.
>
> struct A { void a(); void common(); };
> struct B { void b(); void common(); };
>
> struct X : A, B {
> void x() {
> __super::a(); // __super refers to A here
> __super::b(); // __super refers to B here
> __super::common(); // unable to resolve
> typeid(__super); // unable to resolve
> }
> }
>
> I'm not sure whether it could be useful.
>
In practice, most of the time, there are no conflict so __super is indeed an
usefull shortcut. And in fact, the keyword is the most usefull in MI case.
Also, as I understand, it seems that the compiler uses only implementation
bases and not interface base. If this is the case, then the keyword does
have another advantage of being a bit smarter...
__super would be usable in intialisation list of the constructor and would
be able to call proper inherited constructor(s) provide that there are no
conflict...
Finally, for typeid(__super), it would be possible to consider __super as a
type between X and its bases in most cases.
X *x = new X;
X::_super *s = x;
s->a(); // OK
s->b(); // OK
s->common(); // unable to resolve
typeid(s); // OK: X::_super *
Another uses of __super would be in geniric code. For example, it would be
possible to make some generic code by combining 2 implementation classes and
automatically uses the appropriate base classe because of the keyword. Thus
we can easily have generic code that can refer to implementation code in any
base classe. This is particulary usefull for mix-in code.
Nikolaos D. Bougalis
"KIM Seungbeom" <musi...@bawi.org> wrote in message
news:3E13DABD...@bawi.org...
> "Nikolaos D. Bougalis" wrote:
> >
> > The .NET version of the C++ compiler (13.00 for those keeping count)
has
> > the keyword __super... From the documentation:
> >
> > "The __super keyword allows you to explicitly state that you are calling
a
> > base-class implementation for a function that you are overriding. All
> > accessible base-class methods are considered during the overload
resolution
> > phase, and the function that provides the best match is the one that is
> > called."
>
> Then it means that you cannot know which type __super in itself is
> and that it is meaningful only in the contexts of qualification.
True. The actual type of __super is unknown, in any case where you
inherit from more than one base class, or your base class derives from
another class.
However, the keyword uses normal overload resolution, and the fact that
it fails when normal overload resolution does should not be counted against
it... if you wanted to call common in your example, you'd have to manually
unambiguate the specific implementation of "common" you were referring to,
whether you were using __super or not.
> struct A { void a(); void common(); };
> struct B { void b(); void common(); };
>
> struct X : A, B {
> void x() {
> __super::a(); // __super refers to A here
> __super::b(); // __super refers to B here
> __super::common(); // unable to resolve
> typeid(__super); // unable to resolve
> }
> }
>
> I'm not sure whether it could be useful.
Consider this situation:
struct B1 {
void mf(int) {
// ...
}
};
struct B2 {
void mf(short) {
// ...
}
void mf(char) {
// ...
}
};
struct D : B1, B2 {
void mf(short) {
__super::mf(1); // Calls B1::mf(int)
__super::mf('s'); // Calls B2::mf(char)
}
};
-n
Ken Alverson
> and that it is meaningful only in the contexts of qualification.
>
> struct A { void a(); void common(); };
> struct B { void b(); void common(); };
>
> struct X : A, B {
> void x() {
> __super::a(); // __super refers to A here
> __super::b(); // __super refers to B here
> __super::common(); // unable to resolve
> typeid(__super); // unable to resolve
> }
> }
>
> I'm not sure whether it could be useful.
I think this is *exactly* what many proponents of base/parent/super are
asking for. It seems useful enough to me.
Another useful situation -
struct A {virtual void foo();};
struct C : A {
void foo() {
A::foo();
}
};
Normal enough, but now let's introduce another class
struct A {virtual void foo();};
struct B : A {void foo();};
struct C : B {
void foo() {
A::foo();
}
};
oops! we probably meant to call B::foo here. If we had called
parent::foo(), the compiler would have figured it out for us...instead,
we have an easily missed maintnance bug which leads to a potentially
subtle malfunction.
Ken
KIM Seungbeom
>
> It would be nice if there were a "base" keyword to refer to the previous
> base class, similar to the "this" keyword to the class itself. It would
> sure simplify MFC development. But would that cause problems in situations
> with multiple inheritance (I've never had to work with it before)?
Manual typedef is often suggested as a solution, but people
don't seem to like to suffer from repeating the base class name,
especially if the base class name is complicated:
template<typename charT, typename traits, typename Allocator>
class basic_stringbuf : public basic_streambuf<charT, traits>
{
typedef basic_streambuf<charT, traits> base;
// ...
};
It would be tedious to repeat "basic_streambuf<charT, traits>" here.
And Ken Alverson suggested, in another posting, a maintenance problem
that occured when a new class was introduced into the hierarchy.
Then what do you think of this new syntax?
template<typename charT, typename traits, typename Allocator>
class basic_stringbuf : public base = basic_streambuf<charT, traits>
{
// ...
};
Putting "identifier = " in front of the base class name shall have
the same effect as typedef'ing the base class name as the identifier.
You don't have to repeat the base class name inside the class
definition to give it a new name. There's no maintenance problem
even when a new class is introduced into the hierarchy.
This new syntax doesn't require a new keyword; you just name an
identifier. It has no problems regarding the multiple inheritance;
you can name each base class. Not too hard to implement either, I guess.
I'd like to hear your opinions.
(I don't still agree upon letting one word such as "base" or "super"
represent various bases in multiple inheritances.)
--
KIM Seungbeom <musi...@bawi.org>
Peter Dimov
> no...@jose.dude (Electric Ninja) wrote
> > It would be nice if there were a "base" keyword to refer to the previous
> > base class, similar to the "this" keyword to the class itself. It would
> > sure simplify MFC development. But would that cause problems in situations
> > with multiple inheritance (I've never had to work with it before)?
>
> See Design & Evolution of C++.
>
> The usual answer is that yes, Multiple Inheritance makes the implementation
> of "base" (or "parent") impossible -- and there's no need to find an
> "almost" solution, because we already have an easy workaround.
>
> struct A { ... };
> struct B : public A {
> typedef A parent; // or typedef A base;
> ...
> };
The main problem with the canonical answer is that the base class type
must appear at least twice:
template<class T> struct X: public impl::Y<T, typename
remove_const<T>::type>::type
{
typedef typename impl::Y<T, typename remove_const<T>::type>::type
parent;
};
Redundant, error prone.
Peter Dimov
> "Nikolaos D. Bougalis" wrote:
> >
> > The .NET version of the C++ compiler (13.00 for those keeping count) has
> > the keyword __super... From the documentation:
> >
> > "The __super keyword allows you to explicitly state that you are calling a
> > base-class implementation for a function that you are overriding. All
> > accessible base-class methods are considered during the overload resolution
> > phase, and the function that provides the best match is the one that is
> > called."
>
> Then it means that you cannot know which type __super in itself is
> and that it is meaningful only in the contexts of qualification.
[...]
> I'm not sure whether it could be useful.
It is useful since .NET attributes can automatically inject base
classes; as you don't know their names, the only way to refer to them
is via __super.
KIM Seungbeom
>
> musi...@bawi.org (KIM Seungbeom) wrote in message news:<3E13DABD...@bawi.org>...
> >
> > and that it is meaningful only in the contexts of qualification.
>
> [...]
>
> > I'm not sure whether it could be useful.
>
> It is useful since .NET attributes can automatically inject base
> classes; as you don't know their names, the only way to refer to them
> is via __super.
Oh, can they? Are we talking about C++?
--
KIM Seungbeom <musi...@bawi.org>
Hyman Rosen
> The usual answer is that yes, Multiple Inheritance makes the implementation
> of "base" (or "parent") impossible -- and there's no need to find an
> "almost" solution, because we already have an easy workaround.
No, MI is what makes the implementation *necessary*.
Right now, in order to call a base class method, I
must know in which base class that method is declared.
If there's a workaround at all, it involves using an
intermediate class.
struct baseDEF : public D, public E, public F { };
struct C : public baseDEF { };
Allan W
> Allan W wrote:
> > The usual answer is that yes, Multiple Inheritance makes the implementation
> > of "base" (or "parent") impossible -- and there's no need to find an
> > "almost" solution, because we already have an easy workaround.
>
> No, MI is what makes the implementation *necessary*.
> Right now, in order to call a base class method, I
> must know in which base class that method is declared.
Very interesting! That's an unusual twist on what most people are
asking for with this type of keyword. So "Base" wouldn't refer to
any one particular class; it would instead refer to something along
the lines of
The base class that this name *would* refer to,
if it wasn't overridden by the current class.
Which would make it illegal to use outside of member functions.
There is a wrinkle, though. Base::foo could now be ambiguous.
struct A { void Foo(); };
struct B { void Foo(); };
struct AB : public A, public B {
void Foo() {
Base::Foo(); // Ambiguous! Need A::Foo or B::foo
}
};
> If there's a workaround at all, it involves using an
> intermediate class.
>
> struct baseDEF : public D, public E, public F { };
> struct C : public baseDEF { };
Which seems good enough in most cases.
It has exactly the same problem with ambiguity, though.
struct A { void Foo(); };
struct B { void Foo(); };
struct baseAB : public A, public B {};
struct AB : public baseAB {
typedef baseAB Base;
void Foo() {
Base::Foo(); // Ambiguous! Need A::Foo or B::foo
Ken Alverson
news:7f2735a5.03010...@posting.google.com...
>
> There is a wrinkle, though. Base::foo could now be ambiguous.
>
> struct A { void Foo(); };
> struct B { void Foo(); };
> struct AB : public A, public B {
> void Foo() {
> Base::Foo(); // Ambiguous! Need A::Foo or B::foo
> }
> };
Exactly. Nobody was asking for the compiler to read minds. A compile
error noting the ambiguous call would be the expected behavior here.
The base keyword would act like an imaginary intermediate class, without
needing to actually declare such a class.
Ken
Hyman Rosen
> The base class that this name *would* refer to,
> if it wasn't overridden by the current class.
>
> Which would make it illegal to use outside of member functions.
I don't see why. As you say, 'Base::name' is the (unambiguous,
or an error results) version of name defined by some base class.
Why shouldn't I do 'typedef Base::PtrType *PtrType;', for example?
It would never tbe correct to use Base alone, only to qualify
a name.
Allan W
> "Allan W" <all...@my-dejanews.com> wrote
> > So "Base" wouldn't refer to
> > any one particular class; it would instead refer to something along
> > the lines of
> >
> > The base class that this name *would* refer to,
> > if it wasn't overridden by the current class.
> >
> > Which would make it illegal to use outside of member functions.
> >
> >
> > struct A { void Foo(); };
> > struct B { void Foo(); };
> > struct AB : public A, public B {
> > void Foo() {
> > Base::Foo(); // Ambiguous! Need A::Foo or B::foo
> > }
> > };
>
> Exactly. Nobody was asking for the compiler to read minds. A compile
> error noting the ambiguous call would be the expected behavior here.
> The base keyword would act like an imaginary intermediate class, without
> needing to actually declare such a class.
The idea has merit, but (even though I'm not a compiler writer) I can
forsee problems. The double-colen is called the "Scope Resolution
Operator" (SRO) because it specifies an explicit class. Previously it was
only under very unusual circumstances(*) that a name such as A::B could
be ambiguous.
(*) I believe that the only way an SRO could be ambiguous, is if it was
used from the base of a diamond heirarchy without virtual inheritance.
For instance:
class A { int a; };
class B : public A {};
class C : public A {};
class D : public B, public C {
int getA() { return A::a; } // Error -- ambiguous use of "A::a"
};
But now, we're using "Base::" (or "Parent::" or similar) to say "some
other scope, but not this one." It uses syntax similar to the SRO, but
it has completely different meaning -- almost opposite. And it would be
very easy for that usage to be ambiguous.
I can't think offhand how this would cause problems -- but my gut
instincts tell me that it would severely complicate compilers and/or
programming tools that need to understand class heirarchies.
Would anyone who actually knows, care to comment?
Ken Alverson
> forsee problems. The double-colen is called the "Scope Resolution
> Operator" (SRO) because it specifies an explicit class. Previously it
was
> only under very unusual circumstances(*) that a name such as A::B
could
> be ambiguous.
>
> (*) I believe that the only way an SRO could be ambiguous, is if it
was
> used from the base of a diamond heirarchy without virtual inheritance.
> For instance:
> class A { int a; };
> class B : public A {};
> class C : public A {};
> class D : public B, public C {
> int getA() { return A::a; } // Error -- ambiguous use of
"A::a"
> };
>
> But now, we're using "Base::" (or "Parent::" or similar) to say "some
> other scope, but not this one." It uses syntax similar to the SRO, but
> it has completely different meaning -- almost opposite. And it would
be
> very easy for that usage to be ambiguous.
The following currently compiles with error in vc7 (ambiguous access of
'foo') and comeau ("base::foo" is ambiguous):
struct base1 {
void foo() {}
};
struct base2 {
void foo() {}
};
struct base : base1, base2 {};
struct derived : base {
void bar() {base::foo();}
};
It seems that straightforward implementation of base would pretty much
just involve automatically creating this special immediate parent
pseudoclass (or conceivably even generate a real immediate parent class
with an unspeakable name if that simplified implementation). I don't
see any immediately appearant problems with this; if anybody does,
please speak up.
Ken
Allan W
> Then what do you think of this new syntax?
>
> template<typename charT, typename traits, typename Allocator>
> class basic_stringbuf : public base = basic_streambuf<charT, traits>
> {
> // ...
> };
>
> Putting "identifier = " in front of the base class name shall have
> the same effect as typedef'ing the base class name as the identifier.
I like this! It's simple, it's obvious (now that you've talked about
it), and there's even a precedent in the existing standard (called
"namespace alias").
I'm not sure if it could be ambiguous or not. An equals sign could occur
inside an expression of a template argument. However, the expression
couldn't involve assignment, and furthermore this new syntax would never
be embedded in a template argument. So it seems like it wouldn't be
ambiguous.
> (I don't still agree upon letting one word such as "base" or "super"
> represent various bases in multiple inheritances.)
I'm starting to see that this concept can be useful... But, if that
doesn't happen, I'd at least like to see the "base class alias" in the
next standard.
Allan W
> > I can forsee problems. The double-colen is called the "Scope
> > Resolution Operator" (SRO) because it specifies an explicit
> > class. Previously it was only under very unusual
> > circumstances(*) that a name such as A::B could
> > be ambiguous.
> >
> > (*) I believe that the only way an SRO could be ambiguous, is
> > if it was used from the base of a diamond heirarchy without
> > virtual inheritance. For instance:
> > class A { int a; };
> > class B : public A {};
> > class C : public A {};
> > class D : public B, public C {
> > int getA() { return A::a; }
> > // Error -- ambiguous use of "A::a"
> > };
> The following currently compiles with error in vc7 (ambiguous access of
> 'foo') and comeau ("base::foo" is ambiguous):
>
> struct base1 { void foo() {} };
> struct base2 { void foo() {} };
> struct base : base1, base2 {};
> struct derived : base {
> void bar() {base::foo();}
> };
I should have been more explicit. I meant, "the only time that a
name could specify one and only one member, and yet still be
ambiguous, would be where that class exists more than once in the
heirarchy."
In your case, base::foo is ambiguous because it could refer to
either base1::foo or base2::foo.
If class base had it's own foo, then derived's use of base::foo
would have been unambiguous.
> > But now, we're using "Base::" (or "Parent::" or similar) to say
> > "some other scope, but not this one." It uses syntax similar to
> > the SRO, but it has completely different meaning -- almost
> > opposite. And it would be very easy for that usage to be ambiguous.
> It seems that straightforward implementation of base would pretty much
> just involve automatically creating this special immediate parent
> pseudoclass (or conceivably even generate a real immediate parent class
> with an unspeakable name if that simplified implementation). I don't
> see any immediately appearant problems with this; if anybody does,
> please speak up.
None that I can see. But I'd hate to predict that there wasn't any
problem -- it's pretty far-reaching, or so it seems to me.