"Larry Evans" <cppljevans@cox-internet.com> wrote in message
news:10qd0csbcfprd9a@corp.supernews.com...
> On 11/25/2004 01:33 PM, Dave Harris wrote:
> > cdiggins@videotron.ca ("christopher diggins") wrote (abridged):
> >
> >>I overlooked multiple inheritance in C++. It seems MI is a thorn in the
> [snip]
> > With your suggestion, both() would compile. I think that's undesirable.
> > I'd rather the compiler point out the potential problem. Indeed, it's a
> > drawback of the typedef solution that it might pick the wrong base.
> >
> What about just incorporating the typedef into the specification of
> the bases, i.e.
>
> class D : public B1=TypeExp1, B2=TypeExp2, TypeExp3, B4=TypeExp4
> {};
>
> Where TypeExp_i, for i=1..4 would be anything currently allowed
> in list of base classes, and the B1...B4 would be aliases for
> these type expressions.  No new keywords, and the old syntax would
> still work, as illustrated by the TypeExp3 instead of B3=TypeExp3.

This syntax can already be emulated, as I illustrated before:

  template< [ initial template parameter list ]
                  typename Base1 = TypeExp1,
                  ...
                  typename BaseN = TypeExpN >
  struct D : Base1, ..., BaseN {
     ...
  };

Naturally Base1, ... BaseN should not be documented as template parameters. This
works nicely for classes which are already templates, but is awkward for
non-templates, since you end up having to use D<> instead of D. Of course, you
can use a typedef in this case.

Sometimes I have to use this technique when compiling on VC6 to avoid "X is not
a legal base class" errors.

Jonathan







---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

technews@kangaroologic.com ("Jonathan Turkanis") wrote in message news:<30mkquF317lp4U1@uni-berlin.de>...
> ""christopher diggins"" <cdiggins@videotron.ca> wrote:
>
> > I overlooked multiple inheritance in C++. It seems MI is a thorn in the side
> > for a lot of proposals. If there was an arbitrary significance placed on the
> > first base in an inheritance list, it would provide a workaround for the
> > problem and probably for other proposals which have been stymied by MI. In
> > other words in the case of MI then "inherited" would refer to the first
> > inherited base in the inheritance list.
>
> Introducing an order dependency is almost never a good idea. In fact, much
> work was put into eliminating them in C++. The main problem here is that a
> class author might reorder the bases without realizing that it changes the
> meaning of the code in subtle ways.

So? That's true already. For example, you can't help calling the base
constructors in _some_ order.

#include <stdio.h>

static int i;

class A {   public: A() { i = 0; }   };
class B {   public: B() { i = 1; }   };
class C: public A, public B {};
class D: public B, public A {};

void main()
{
 C c;
 printf( "After C(), i = %d\n", i );
 D d;
 printf( "After D(), i = %d\n", i );
}

--
Laurie Cheers

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Larry Evans wrote:
> On 11/27/2004 11:51 AM, Seungbeom Kim wrote:
>
>>
>> I had proposed in news:comp.std.c++ a new syntax which is not confused
>> by multiple inheritance:
>> ( http://groups.google.com/groups?selm=3E155673.A7BAF654%40bawi.org )
>>
>> template<typename charT, typename traits, typename Allocator>
>> class basic_stringbuf : public base = basic_streambuf<charT, traits>
>> {
>>     // ...
>> };
>>
>
> Looks pretty good to me :)
>
> BTW, I really hadn't seen the above post; otherwise, I would
> have cited it in my previous post to this thread.
>
> OTOH, I've been trying to figure some flaw, but the only disadvantage
> I can think of is that maybe it requires a 2 token lookahead to
> determine if the identifier should be a typeid or an alias for
> a typeid.  If that's the problem, then I don't see why just
> repeating the whole typedef syntax would be possible.  I.e.
>
> class Derived : public
>   typedef TypeExp1 alias1
> , base2
> , typedef TypeExp3 alias3
> {};
>
> Then the only difference between parsing a typedef in the body of
> the class and in the base list is the terminating characters.  In the
> first case, it's ';', in the last it's either '{' or ','.

Thanks for pointing that out that I didn't think of.
Another option that I guess does not have the problem with parsing is:

class Derived : public Base1 = alias1, Base2, Base3 = alias2 { };

More succinct, and less to type than "typedef". :)

By the way, I'm almost sure that making "inherited" a keyword (and
"self" too, maybe) will break _a lot of_ of existing code, because many
programmers would have used it as a typedef name for the same purpose:

template<typename charT, typename traits, typename Allocator>
class basic_stringbuf : public basic_streambuf<charT, traits>
{
     typedef basic_streambuf<charT, traits> inherited;
     // ...
};

It's better to adopt a new syntax that allows aliasing of the necessary
types without repeating their names. (As you might well know, repetition
is bad not only because of more typing but also to keep consistency.)

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Laurie Cheers" <laurie.cheers@btinternet.com> wrote in message:
> technews@kangaroologic.com ("Jonathan Turkanis") wrote in message:
> > ""christopher diggins"" <cdiggins@videotron.ca> wrote:
> >

> > Introducing an order dependency is almost never a good idea. In fact, much
> > work was put into eliminating them in C++. The main problem here is that a
> > class author might reorder the bases without realizing that it changes the
> > meaning of the code in subtle ways.
>
> So? That's true already. For example, you can't help calling the base
> constructors in _some_ order.

The alternative would be to leave the order of initialization unspecified, and I
think it's clear that that would be undesirable. But I don't see how it affects
the argument -- I'm arguing against introducing additional order dependencies.

> Laurie Cheers

Jonathan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:
> Alberto Barbati wrote:
>
>> James Dennett wrote:
>>
>>>
>>> self, or this_type, might be more viable.
>>>
>>
>> #define self decltype(*this)
>>
>> ;-)
>
>
> Smilie noted; but self would be of most use in contexts
> where there is no "this" to which to refer.

 What are those contexts in which there is no "this" and what would
"self" refer to in those cases?

 -n

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nikolaos D. Bougalis wrote:

> James Dennett wrote:
>
>> Alberto Barbati wrote:
>>
>>> James Dennett wrote:
>>>
>>>>
>>>> self, or this_type, might be more viable.
>>>>
>>>
>>> #define self decltype(*this)
>>>
>>> ;-)
>>
>>
>>
>> Smilie noted; but self would be of most use in contexts
>> where there is no "this" to which to refer.
>
>
>     What are those contexts in which there is no "this" and what would
> "self" refer to in those cases?

Within a class, but not within a non-static member function.

struct S {
  // here

  static void a() { /* and here */ }

  static void b();
};

void S::b() { /* and here */ }

In both cases, self would refer to the class S.

-- James

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nikolaos D. Bougalis wrote:

>     What are those contexts in which there is no "this" and what would
> "self" refer to in those cases?

In addition to the answer of James Dennett;
"this" can be used only in an expression, while "self" is meant to be
used as a type and types can be used in other contexts too.

template <typename T, typename U, typename V>
class very_long_name_class
{
     // self == very_long_name_class<T, U, V>
     self& operator=(const self& other);
};

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim wrote:
> Nikolaos D. Bougalis wrote:
>
>>     What are those contexts in which there is no "this" and what would
>> "self" refer to in those cases?
>
>
> In addition to the answer of James Dennett;
> "this" can be used only in an expression, while "self" is meant to be
> used as a type and types can be used in other contexts too.
>
> template <typename T, typename U, typename V>
> class very_long_name_class
> {
>     // self == very_long_name_class<T, U, V>
>     self& operator=(const self& other);
> };

 Good point. Thanks,

 -n

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:
>
> self, or this_type, might be more viable.
>

#define self decltype(*this)

;-)

Alberto

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I think C++ could use keywords akin to the Heron keywords "self" and
> "inherited" which refer to the type of the current class and the parent
> class repsectively.

Read Bjarne Stroustrup's, "The Design and Evolution of C++".
"Inherited" is discussed in there and drawbacks noted viz "multiple
inheritance".

Cheers

Stephen Howe


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:yfepd.171196$hj.119273@fed1read07...
> christopher diggins wrote:
>> Are there are any proposal along this line? Any other interest in such a
>> proposal?
>>
>
> "inherited" has been discussed endlessly, along with its limitations
> in the world of multiple inheritance and numerous proposed ways to
> work around that; in the end, IMO, no convincing proposal has been
> produced.
>
> self, or this_type, might be more viable.
>
> -- James


Thanks for the response,

I overlooked multiple inheritance in C++. It seems MI is a thorn in the side
for a lot of proposals. If there was an arbitrary significance placed on the
first base in an inheritance list, it would provide a workaround for the
problem and probably for other proposals which have been stymied by MI. In
other words in the case of MI then "inherited" would refer to the first
inherited base in the inheritance list.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:yfepd.171196$hj.119273@fed1read07...
> christopher diggins wrote:
>> I think C++ could use keywords akin to the Heron keywords "self" and
>> "inherited" which refer to the type of the current class and the parent
>> class repsectively. The following code seems needless:
>>
>>   template<typename Elem_T>
>>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>>   {
>>     typedef typename Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>> inherited;
>>     typedef typename Array<Elem_T> self;
>>     Array(const self& x) : inherited(x) { };
>>     ...
>>   };
>>
>> When with decent keywords it could be rewritten as:
>>
>>   template<typename Elem_T>
>>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>>   {
>>
>>     Array(const self& x) : inherited(x) { };
>>     ...
>>   };
>>
>> Are there are any proposal along this line? Any other interest in such a
>> proposal?
>>
>
> "inherited" has been discussed endlessly, along with its limitations
> in the world of multiple inheritance and numerous proposed ways to
> work around that; in the end, IMO, no convincing proposal has been
> produced.
>
> self, or this_type, might be more viable.
>

   self would be extremely useful if the proposal for delegating
constructors passes (see
http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1618.pdf).

Joe Gottman

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Joe Gottman"" <jgottman@carolina.rr.com> wrote in message
news:HVlpd.806$Mu3.399422@twister.southeast.rr.com...
|
| "James Dennett" <jdennett@acm.org> wrote in message
| news:yfepd.171196$hj.119273@fed1read07...
| > christopher diggins wrote:
| >> I think C++ could use keywords akin to the Heron keywords "self" and
| >> "inherited" which refer to the type of the current class and the parent
| >> class repsectively. The following code seems needless:

| > "inherited" has been discussed endlessly, along with its limitations
| > in the world of multiple inheritance and numerous proposed ways to
| > work around that; in the end, IMO, no convincing proposal has been
| > produced.
| >
| > self, or this_type, might be more viable.
| >
|
|   self would be extremely useful if the proposal for delegating
| constructors passes (see
| http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1618.pdf).

why not just reuse this?

-Thorsten


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote (abridged):
> I overlooked multiple inheritance in C++. It seems MI is a thorn in the
> side for a lot of proposals. If there was an arbitrary significance
> placed on the first base in an inheritance list, it would provide a
> workaround for the problem and probably for other proposals which have
> been stymied by MI. In other words in the case of MI then "inherited"
> would refer to the first inherited base in the inheritance list.

There's no need to make the first base class special. The semantics of
"inherited" can be something like, "use what the definition would be if it
wasn't declared in this class", and the usual ambiguity rules applied.
Thus:

    struct Base1 { void first(); void both(); }
    struct Base2 { void second(); void both(); }

    struct Derived: Base1, Base2 {
        void first() {
            inherited::first(); // Base1::first().
        }
        void second() {
            inherited::second(); // Base2::second().
        }
        void both() {
            inherited::both(); // Error - ambiguous.
        }
    }

With your suggestion, second() wouldn't compile, but there's no reason why
it shouldn't and it could be useful.

With your suggestion, both() would compile. I think that's undesirable.
I'd rather the compiler point out the potential problem. Indeed, it's a
drawback of the typedef solution that it might pick the wrong base.

-- Dave Harris, Nottingham, UK

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""christopher diggins"" <cdiggins@videotron.ca> wrote:

> I overlooked multiple inheritance in C++. It seems MI is a thorn in the side
> for a lot of proposals. If there was an arbitrary significance placed on the
> first base in an inheritance list, it would provide a workaround for the
> problem and probably for other proposals which have been stymied by MI. In
> other words in the case of MI then "inherited" would refer to the first
> inherited base in the inheritance list.

Introducing an order dependency is almost never a good idea. In fact, much work
was put into eliminating them in C++. The main problem here is that a class
author might reorder the bases without realizing that it changes the meaning of
the code in subtle ways.

It would be better to let uses of "inherited" be ambiguous in contexts where it
could refer to more than one base class, since otherwise  these cases would
often represent undetected errors. This is mentioned in the D&E discussion, too.

Jonathan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"christopher diggins" wrote:
> I overlooked multiple inheritance in C++. It seems MI is a thorn in
the side
> for a lot of proposals. If there was an arbitrary significance placed
on the
> first base in an inheritance list, it would provide a workaround for
the
> problem and probably for other proposals which have been stymied by
MI. In
> other words in the case of MI then "inherited" would refer to the
first
> inherited base in the inheritance list.

Personally, I think both 'self' and 'inherited' are dead in the water
but
anyway: Assuming that you want to arbitrarily choose one of the base
classes, it should *not* simply be the first but probably the first
non-private base class. I use private base class in quite a lot
situation
to construct members which require early initialization or late
destruction
for whatever reason. I think this not such a rare use of multiple
inheritance.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<dietmar_kuehl@yahoo.com> wrote in message
news:1101405739.609911.34390@f14g2000cwb.googlegroups.com...
> "christopher diggins" wrote:
> > I overlooked multiple inheritance in C++. It seems MI is a thorn in
> the side
> > for a lot of proposals. If there was an arbitrary significance placed
> on the
> > first base in an inheritance list, it would provide a workaround for
> the
> > problem and probably for other proposals which have been stymied by
> MI. In
> > other words in the case of MI then "inherited" would refer to the
> first
> > inherited base in the inheritance list.
>
> Personally, I think both 'self' and 'inherited' are dead in the water
> but
> anyway: Assuming that you want to arbitrarily choose one of the base
> classes, it should *not* simply be the first but probably the first
> non-private base class.

This would make the access specifiers for base classes work differently to
access specifiers for class members - where the access level doesn't change
the meaning (access and visibility being orthogonal) - which could be rather
non-intuitive. I agree with Jonathan that attaching special meaning to the
order of the base classes is probably a bad idea, and I think the same goes
for treating the access specifiers differently.

Also, as you say, I don't see much point in "self" or "inherited": With
class templates, as Jonathan points out, you can use the name of the class
template to mean the class template specialisation - in OPs example, "Array"
= "self". Using a base class template can involve more typing, though, as OP
shows, but due to MI, "inherited" (as defined by OP) won't work for this.
Dave Harris has an interesting suggestion for how "inherited" might work,
also in the case of MI, though.

Regards,

Terje


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 11/25/2004 01:33 PM, Dave Harris wrote:
> cdiggins@videotron.ca ("christopher diggins") wrote (abridged):
>
>>I overlooked multiple inheritance in C++. It seems MI is a thorn in the
[snip]
> With your suggestion, both() would compile. I think that's undesirable.
> I'd rather the compiler point out the potential problem. Indeed, it's a
> drawback of the typedef solution that it might pick the wrong base.
>
What about just incorporating the typedef into the specification of
the bases, i.e.

class D : public B1=TypeExp1, B2=TypeExp2, TypeExp3, B4=TypeExp4
{};

Where TypeExp_i, for i=1..4 would be anything currently allowed
in list of base classes, and the B1...B4 would be aliases for
these type expressions.  No new keywords, and the old syntax would
still work, as illustrated by the TypeExp3 instead of B3=TypeExp3.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:

> There's no need to make the first base class special. The semantics of
> "inherited" can be something like, "use what the definition would be if it
> wasn't declared in this class", and the usual ambiguity rules applied.
> Thus:
>
>     struct Base1 { void first(); void both(); }
>     struct Base2 { void second(); void both(); }
>
>     struct Derived: Base1, Base2 {
>         void first() {
>             inherited::first(); // Base1::first().
>         }
>         void second() {
>             inherited::second(); // Base2::second().
>         }
>         void both() {
>             inherited::both(); // Error - ambiguous.
>         }
>     }

Then what is the type of inherited? Is it a type or not?

I had proposed in news:comp.std.c++ a new syntax which is not confused
by multiple inheritance:
( http://groups.google.com/groups?selm=3E155673.A7BAF654%40bawi.org )

template<typename charT, typename traits, typename Allocator>
class basic_stringbuf : public base = basic_streambuf<charT, traits>
{
     // ...
};

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<mt2pd.66115$3u6.1960853@wagner.videotron.net>...
> I think C++ could use keywords akin to the Heron keywords "self" and
> "inherited" which refer to the type of the current class and the parent
> class repsectively. The following code seems needless:

typedef decltype(*this) self; // C++0x

"The" parent class of course doesn't exist.

Regards,
Michiel Salters

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Jonathan Turkanis"" <technews@kangaroologic.com> wrote in message
news:30mkquF317lp4U1@uni-berlin.de...
>
> ""christopher diggins"" <cdiggins@videotron.ca> wrote:
>
>> I overlooked multiple inheritance in C++. It seems MI is a thorn in the
>> side
>> for a lot of proposals. If there was an arbitrary significance placed on
>> the
>> first base in an inheritance list, it would provide a workaround for the
>> problem and probably for other proposals which have been stymied by MI.
>> In
>> other words in the case of MI then "inherited" would refer to the first
>> inherited base in the inheritance list.
>
> Introducing an order dependency is almost never a good idea. In fact, much
> work
> was put into eliminating them in C++. The main problem here is that a
> class
> author might reorder the bases without realizing that it changes the
> meaning of
> the code in subtle ways.
>
> It would be better to let uses of "inherited" be ambiguous in contexts
> where it
> could refer to more than one base class, since otherwise  these cases
> would
> often represent undetected errors. This is mentioned in the D&E
> discussion, too.
>
> Jonathan

Good point, I wholeheartedly agree. Let's just ban multiple inheritance of
classes then.

>;-)

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 11/27/2004 11:51 AM, Seungbeom Kim wrote:
>
> I had proposed in news:comp.std.c++ a new syntax which is not confused
> by multiple inheritance:
> ( http://groups.google.com/groups?selm=3E155673.A7BAF654%40bawi.org )
>
> template<typename charT, typename traits, typename Allocator>
> class basic_stringbuf : public base = basic_streambuf<charT, traits>
> {
>     // ...
> };
>

Looks pretty good to me :)

BTW, I really hadn't seen the above post; otherwise, I would
have cited it in my previous post to this thread.

OTOH, I've been trying to figure some flaw, but the only disadvantage
I can think of is that maybe it requires a 2 token lookahead to
determine if the identifier should be a typeid or an alias for
a typeid.  If that's the problem, then I don't see why just
repeating the whole typedef syntax would be possible.  I.e.

class Derived : public
   typedef TypeExp1 alias1
, base2
, typedef TypeExp3 alias3
{};

Then the only difference between parsing a typedef in the body of
the class and in the base list is the terminating characters.  In the
first case, it's ';', in the last it's either '{' or ','.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alberto Barbati wrote:
> James Dennett wrote:
>
>>
>> self, or this_type, might be more viable.
>>
>
> #define self decltype(*this)
>
> ;-)

Smilie noted; but self would be of most use in contexts
where there is no "this" to which to refer.

-- James

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim wrote:
> Dave Harris wrote:
>=20
>> There's no need to make the first base class special. The semantics of=
=20
>> "inherited" can be something like, "use what the definition would be=20
>> if it wasn't declared in this class", and the usual ambiguity rules=20
>> applied. Thus:
>>
>>     struct Base1 { void first(); void both(); }
>>     struct Base2 { void second(); void both(); }
>>         struct Derived: Base1, Base2 {
>>         void first() {
>>             inherited::first(); // Base1::first().
>>         }
>>         void second() {
>>             inherited::second(); // Base2::second().
>>         }
>>         void both() {
>>             inherited::both(); // Error - ambiguous.
>>         }
>>     }
>=20
>=20
> Then what is the type of inherited? Is it a type or not?
>=20

If I understand the proposal, it's not a type. The presence of=20
"inherited::" before a name simply forces a member name lookup (=A710.2)=20
of the name with the important difference that all declarations in the=20
current class are not considered. As it affects only the lookup of some=20
other name, the keyword should never be used alone.

Frankly, I like the idea very much, although I agree that it may be=20
confusing as one might believe it's legal to use inherited in ctor=20
initializers or to make type-ids.

Alberto

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (Seungbeom Kim) wrote (abridged):
> Then what is the type of inherited? Is it a type or not?

I'm guessing it's not a type, no more than a namespace is a type. It is
about scope resolution. I don't think you'd be able to use, eg,
sizeof(inherited) even if there was only one base class.

(By the way, the idea isn't original to me - it's in D&E $13.6.)

-- Dave Harris, Nottingham, UK

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I think C++ could use keywords akin to the Heron keywords "self" and
"inherited" which refer to the type of the current class and the parent
class repsectively. The following code seems needless:

  template<typename Elem_T>
  struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
  {
    typedef typename Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
inherited;
    typedef typename Array<Elem_T> self;
    Array(const self& x) : inherited(x) { };
    ...
  };

When with decent keywords it could be rewritten as:

  template<typename Elem_T>
  struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
  {

    Array(const self& x) : inherited(x) { };
    ...
  };

Are there are any proposal along this line? Any other interest in such a
proposal?

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

christopher diggins wrote:
> I think C++ could use keywords akin to the Heron keywords "self" and
> "inherited" which refer to the type of the current class and the parent
> class repsectively. The following code seems needless:
>
>   template<typename Elem_T>
>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>   {
>     typedef typename Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
> inherited;
>     typedef typename Array<Elem_T> self;
>     Array(const self& x) : inherited(x) { };
>     ...
>   };
>
> When with decent keywords it could be rewritten as:
>
>   template<typename Elem_T>
>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>   {
>
>     Array(const self& x) : inherited(x) { };
>     ...
>   };
>
> Are there are any proposal along this line? Any other interest in such a
> proposal?
>

"inherited" has been discussed endlessly, along with its limitations
in the world of multiple inheritance and numerous proposed ways to
work around that; in the end, IMO, no convincing proposal has been
produced.

self, or this_type, might be more viable.

-- James

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"christopher diggins" <cdiggins@videotron.ca> wrote in message:

Hi Christopher,

> I think C++ could use keywords akin to the Heron keywords "self" and
> "inherited" which refer to the type of the current class and the parent
> class repsectively. The following code seems needless:
>
>   template<typename Elem_T>
>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>   {
>     typedef typename Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
> inherited;
>     typedef typename Array<Elem_T> self;
>     Array(const self& x) : inherited(x) { };
>     ...
>   };

The typedef self is unnecessary here, since Array without a template argument
list is equivalent in this context to Array<Elem_T>. (See 14.6.1)

> When with decent keywords it could be rewritten as:
>
>   template<typename Elem_T>
>   struct Array : public Array_wrapper<Array_impl<Elem_T>, Elem_T>::type
>   {
>
>     Array(const self& x) : inherited(x) { };
>     ...
>   };

How about:

  template< typename Elem_T,
            typename Base =
                typename
                Array_wrapper<
                    Array_impl<Elem_T>, Elem_T
                >::type >
  struct Array : Base
  {
      Array(const Array& x) : Base(x) { };
      ...
  };

?

It's a bit funny looking -- but it's legal and involves no redundancy.

> Are there are any proposal along this line? Any other interest in such a
> proposal?

Bjarne Stroustrup discusses the proposal for an "inherited" keyword in D&E p
290. Basically, the solution using typedefs was considered good enough given all
the other proposed extensions that deserved to be considered. The example Bjarne
gives is

   class manager : public foreman {
       typedef foreman inherited;
       // ...
   };

I think this example would probably not be as convincing if the base class were
Array_wrapper<Array_impl<Elem_T>, Elem_T>::type.

Jonathan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]