Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<KKF3eKA+RZ77Ew98@ntlworld.com>...
> The interfaces of an explicit base are
> imported into the derived class (and that possibly includes the ctors)
> with exactly the same access as in the base. However there is no
> implicit derived to base conversion and any overridden implementations
> of base class members will supersede the base version.

I don't know how many people have independently invented and requested
this.  I suspect it's lots.  I'll add
(news:<1em1tw7.1chou0x1slo3kN%jthill@telus.net>) mine to the list,
from last December.  I used (and still prefer) `auto` rather than
`explicit`.  I think auto should affect only the specials. If you want
to hide the D->B conversion, how about declaring operator B& private?
I'm not sure that will have the desired effect with the current
standard, but I really dislike tying base accessibility to anything
but the access keywords.

I also dislike

> virtual bases are always treated as public

because it makes `virtual private Final` (where `class   Final{};`) not
do what I want compilers to eventually recognize as its current
meaning: cannot be derived from.

Jim

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <a8af2f56.0111211958.28809202@posting.google.com>, Jim Hill=20
<jthill_@mac.com> writes
>Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message ne=
ws:<KKF3eKA+RZ77Ew98@ntlworld.com>...
>> The interfaces of an explicit base are
>> imported into the derived class (and that possibly includes the ctors)
>> with exactly the same access as in the base. However there is no
>> implicit derived to base conversion and any overridden implementations
>> of base class members will supersede the base version.
>
>I don't know how many people have independently invented and requested
>this.  I suspect it's lots.  I'll add
>(news:<1em1tw7.1chou0x1slo3kN%jthill@telus.net>) mine to the list,
>from last December.  I used (and still prefer) `auto` rather than
>`explicit`.  I think auto should affect only the specials. If you want
>to hide the D->B conversion, how about declaring operator B& private?
>I'm not sure that will have the desired effect with the current
>standard, but I really dislike tying base accessibility to anything
>but the access keywords.

Thanks for the thoughts. I and my UK colleagues have a number of ideas=20
and we are currently leaning towards providing some form of using=20
directive for classes which would achieve the same end.
>
>I also dislike
>
>> virtual bases are always treated as public
>
>because it makes `virtual private Final` (where `class=A0Final{};`) not
>do what I want compilers to eventually recognize as its current
>meaning: cannot be derived from.

Yes, and as consideration of 'final' as a keyword is among the things we=20
are doing that point is well taken.


--=20
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> The current C++ Standard has three fundamental forms of inheritance:
> public, protected and private. Superficially each of these has an extra
[SNIP]
> We have already made it possible to remove implicit conversions by ctor
> by introducing 'explicit'. There are proposals around that this should
> be extended to conversion operators. Now I would like your opinions on
> introducing explicit bases. The interfaces of an explicit base are
> imported into the derived class (and that possibly includes the ctors)
> with exactly the same access as in the base. However there is no
> implicit derived to base conversion and any overridden implementations
> of base class members will supersede the base version.
>
> As a further clean up I would like to see:
>
> public, virtual and explicit bases have the same access as is currently
> given to public bases (i.e. virtual bases are always treated as public
> regardless as to any added access qualifier)
>
> protected and private as they are now.
>
> Thoughts?

I can only comment about the _addition_ of explicit.  YES, I'd like to
see something like this.  Definitely.  I hate if I need to derive from
std::string or something like that I have to re-do every constructor at
least - for no good reason.

I did not write here as a proposal, because I did not think enough about
it.  But sometimes (esp. rapid prototyping) it would just be so nice, to
create a new class (which I know _will_ have some differences later)
from string.  Why not  a typedef?  'cause I cannot overload on a
typedef.  Nowadays I have to write awfully lot to get such a class and
make it work as a string.  Now if I could do as step 1:

class WhateverName : explicit std::string {};

Now that would be _easy_.  Later, if I find out what I need to _change_
compared to string, I could do:

class WhateverName : explicit std::string {
   somefuncIwantohide(.....) { fwded to std::string; )
public:
   ...op+=(....){
      some special tests to ensure length or whatever
   }
};

etc.  And I would never ever need to know the 10000 possibilities of
construction, I would just inherit them.  Of course, I could inherit
something unexpected as well...  So I am not 100% sure, that my _final_
class would not use private inheritance.  However if it is just a plain
string, with another name... it would be quite nice to have this
explicit inheritance to make an alias, which can be used in overloading.

I was also thinking about "extending" the using directive.  Like that I
could say:

using public std::string;

and bring the _whole_ public I/F in at that point.

To the other extreme, I could say:

using MyBase::f(int);

if I do not need _all_ the f overloaded versions.

I had even another idea, of supporting the same "simple way" of asking
for delegation for members:

Will create functions for all overloads of funct, inline ones,
delegating to the member::funct.  Should work also for members, which
are pointers:

somekeyword member::funct;

somekeyword could be auto?

auto xptr_::valid;

auto xptr::whatever( int);

The latter would _only_ create a delegator for the int overload of
whatever.

Just toughts. :-)

A

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:

> In article <3BF4405A.9020105@acm.org>, James Dennett <jdennett@acm.org>
> writes
>
>>It works *nearly* as well if cannotderive is a public
>>base, but you're part of the campaign for avoiding
>>unwanted conversions to base classes, so you should
>>approve of the desire to make it private.
>>
>
> No, my campaign is to make the language simpler and more intuitive. I
> think the 'cannotderive' mechanism is a horrible hack and we should look
> for a better solution to that.

An explicit way to mark classes as "final" might avoid
the endless discussions of how to do it.  That said, a
recent discussion convinced me that there's little
reason to make a class "final" in C++, so adding "final"
(in some form) may not be worthwhile.

-- James Dennett

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<4Wt7ZIAGjF97EwLq@ntlworld.com>...
> In article <3BF4405A.9020105@acm.org>, James Dennett <jdennett@acm.org>
> writes
> >It works *nearly* as well if cannotderive is a public
> >base, but you're part of the campaign for avoiding
> >unwanted conversions to base classes, so you should
> >approve of the desire to make it private.
>
> No, my campaign is to make the language simpler and more intuitive. I
> think the 'cannotderive' mechanism is a horrible hack and we should look
> for a better solution to that.

Agreed 100%.

Solution #1: 'final.' Handy for member functions, too.
Solution #2: make people read the documentation where it says
'deriving from class X invokes undefined behavior.'

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:

> In article <3BF01CDA.4020302@acm.org>, James Dennett <jdennett@acm.org>
> writes
>
>>Yes you can.
>>
>>class A;
>>
>>
>>
>>>class cannotderive {
>>>
>>>// whatever
>>>
>>
>> friend class A;
>> cannotderive() { }; // private ctor
>>
>>
>>
>>>};
>>>
>>>class A : virtual private cannotderive {
>>>
>>>// whatever
>>>
>>>};
>>>
>>No class can derive further from A because it would have to
>>initialize cannotderive, which has only private constructors
>>(and you can make a private copy constructor if you're truly
>>paranoid).
>>
>
> What has that got to do with the cannotderive being a *private* virtual
> base?


The idiom makes it private; converting to a cannotderive
makes no sense, so it should ideally not be part of the
public interface of class A.

Granted, virtual bases are usually part of the interface
even if they're private, precisely because of the need to
initialize them in derived classes.  In this situation,
however, derived classes do not need to know about the
fact that cannotderive is a base class -- they can't
initialize it, and doing anything else with it is
pointless.

> The important features are that it is a virtual base with a
> private ctor. It works just as well if cannotderive is a public virtual
> base so this is not a counter argument to my proposal.


It works *nearly* as well if cannotderive is a public
base, but you're part of the campaign for avoiding
unwanted conversions to base classes, so you should
approve of the desire to make it private.

-- James Dennett



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3BF4405A.9020105@acm.org>, James Dennett <jdennett@acm.org>
writes
>It works *nearly* as well if cannotderive is a public
>base, but you're part of the campaign for avoiding
>unwanted conversions to base classes, so you should
>approve of the desire to make it private.

No, my campaign is to make the language simpler and more intuitive. I
think the 'cannotderive' mechanism is a horrible hack and we should look
for a better solution to that.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

The current C++ Standard has three fundamental forms of inheritance:
public, protected and private. Superficially each of these has an extra
flavour of virtual. I say superficially because effectively any virtual
base should be treated as if it is public. I hope I do not need to
explain that here.

Now none of these types makes inheritance of implementation easy. We
tell people that they should use private inheritance for this purpose
and they should meticulously republish the public and protected
interfaces with using declarations (ignoring the fact that that cannot
be done correctly that way if there is a function that has overloads
some of which are public and some are protected)

Now I have been continuing to think about how we could make inheritance
of implementation easier and thereby more frequently used. A serious
problem with public inheritance is that it exposes a derived to base
implicit conversion.

We have already made it possible to remove implicit conversions by ctor
by introducing 'explicit'. There are proposals around that this should
be extended to conversion operators. Now I would like your opinions on
introducing explicit bases. The interfaces of an explicit base are
imported into the derived class (and that possibly includes the ctors)
with exactly the same access as in the base. However there is no
implicit derived to base conversion and any overridden implementations
of base class members will supersede the base version.

As a further clean up I would like to see:

public, virtual and explicit bases have the same access as is currently
given to public bases (i.e. virtual bases are always treated as public
regardless as to any added access qualifier)

protected and private as they are now.

Thoughts?

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> We have already made it possible to remove implicit conversions by
ctor
> by introducing 'explicit'. There are proposals around that this should
> be extended to conversion operators. Now I would like your opinions on
> introducing explicit bases. The interfaces of an explicit base are
> imported into the derived class (and that possibly includes the ctors)
> with exactly the same access as in the base. However there is no
> implicit derived to base conversion and any overridden implementations
> of base class members will supersede the base version.

This sounds logical but it doesn't really provide anything I need.

Generally when I am messing around with implementation inheritance, ie
without providing Liskov Substitutability, I want to have complete
control over what interface clients see. For example, I might provide a
specialised form of erase() and momentarily forget about clear(). I
don't want clients to be able to call clear() and so by-pass my special
erase() logic. I want the interface to include only functions I have
specifically decided are safe.

Explicit public inheritance would be too much of a blunderbuss for me.
It exposes functions that I may not even know exist. Who can say what
will be added to std::vector in the next version of C++?


> Now I have been continuing to think about how we could make
inheritance
> of implementation easier and thereby more frequently used. A serious
> problem with public inheritance is that it exposes a derived to base
> implicit conversion.

Can your problem be solved by library additions instead of language
changes?

Maybe what we really need is a version of std::vector which is designed
to be inherited from. Such a base class would have a virtual destructor,
a virtual erase() and perhaps a non-virtual clear() which guaranteed to
invoke the virtual erase().

I suppose I am seeing it as black-and-white. Either inheritance is
public and provides LSP, or it isn't. Either the base class is designed
for inheritance or it isn't. "Public explicit" is a kind of half-way
house, almost an oxymoron. Does it really lead to good designs?


> Now none of these types makes inheritance of implementation easy. We
> tell people that they should use private inheritance for this purpose
> and they should meticulously republish the public and protected
> interfaces with using declarations (ignoring the fact that that cannot
> be done correctly that way if there is a function that has overloads
> some of which are public and some are protected)

In my view this is the real problem. Using-declarations would be safer
if they could specify the signature of the function they introduce.

For example, I should be able to have:

    struct MyVec : private vector<int> {
         using vector<int>::begin() const;
    };

and be sure of getting only the const version of begin(), not the
non-const. I want a precise, surgical tool for composing interfaces.


> (and that possibly includes the ctors)

"Inheritance" of constructors is a whole new kettle of fish. Again I
feel using-declarations are a more appropriate tool.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:KKF3eKA+RZ77Ew98@ntlworld.com...
> public, virtual and explicit bases have the same access as is currently
> given to public bases (i.e. virtual bases are always treated as public
> regardless as to any added access qualifier)

You can use private virtual inheritance to enforce that a class cannot be
derived from. Making virtual==public would prevent that.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9so3e6$14c8ql$1@ID-49767.news.dfncis.de>, Anthony Williams
<anthwil@nortelnetworks.com> writes
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>news:KKF3eKA+RZ77Ew98@ntlworld.com...
>> public, virtual and explicit bases have the same access as is currently
>> given to public bases (i.e. virtual bases are always treated as public
>> regardless as to any added access qualifier)
>
>You can use private virtual inheritance to enforce that a class cannot be
>derived from. Making virtual==public would prevent that.

No you cannot:

class cannotderive {

// whatever
};

class A : virtual private cannotderive {

// whatever

};


class A1 : public class A, virtual public cannotderive {

// whatever

};

You cannot use A as a simple direct base but you can use A1.


Yes, it takes some deliberation. The idiom for making a class that
cannot be derived is somewhat different.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:

> In article <9so3e6$14c8ql$1@ID-49767.news.dfncis.de>, Anthony Williams
> <anthwil@nortelnetworks.com> writes
>
>>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>>news:KKF3eKA+RZ77Ew98@ntlworld.com...
>>
>>>public, virtual and explicit bases have the same access as is currently
>>>given to public bases (i.e. virtual bases are always treated as public
>>>regardless as to any added access qualifier)
>>>
>>You can use private virtual inheritance to enforce that a class cannot be
>>derived from. Making virtual==public would prevent that.
>>
>
> No you cannot:


Yes you can.

class A;


>
> class cannotderive {
>
> // whatever


   friend class A;
   cannotderive() { }; // private ctor


> };
>
> class A : virtual private cannotderive {
>
> // whatever
>
> };

No class can derive further from A because it would have to
initialize cannotderive, which has only private constructors
(and you can make a private copy constructor if you're truly
paranoid).

-- James Dennett

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3BF01CDA.4020302@acm.org>, James Dennett <jdennett@acm.org>
writes
>Yes you can.
>
>class A;
>
>
>>
>> class cannotderive {
>>
>> // whatever
>
>
>  friend class A;
>  cannotderive() { }; // private ctor
>
>
>> };
>>
>> class A : virtual private cannotderive {
>>
>> // whatever
>>
>> };
>
>No class can derive further from A because it would have to
>initialize cannotderive, which has only private constructors
>(and you can make a private copy constructor if you're truly
>paranoid).

What has that got to do with the cannotderive being a *private* virtual
base? The important features are that it is a virtual base with a
private ctor. It works just as well if cannotderive is a public virtual
base so this is not a counter argument to my proposal.



Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:yRMJIgAGjC87EwzD@ntlworld.com...
> In article <3BF01CDA.4020302@acm.org>, James Dennett <jdennett@acm.org>
> writes
> >Yes you can.
> >
> >class A;
> >
> >
> >>
> >> class cannotderive {
> >>
> >> // whatever
> >
> >
> >  friend class A;
> >  cannotderive() { }; // private ctor
> >
> >
> >> };
> >>
> >> class A : virtual private cannotderive {
> >>
> >> // whatever
> >>
> >> };
> >
> >No class can derive further from A because it would have to
> >initialize cannotderive, which has only private constructors
> >(and you can make a private copy constructor if you're truly
> >paranoid).
>
> What has that got to do with the cannotderive being a *private* virtual
> base? The important features are that it is a virtual base with a
> private ctor. It works just as well if cannotderive is a public virtual
> base so this is not a counter argument to my proposal.

If cannotderive is a public base, then you are open to derived-to-base
conversions.

cannotderive* cdp=new A;
delete cdp; // undefined behaviour if ~A() has content

If you prevent private virtual bases, then you have to add the overhead of a
virtual destructor to cannotderive, for no real purpose.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
[...]
> Now none of these types makes inheritance of implementation easy. We
> tell people that they should use private inheritance for this purpose
> and they should meticulously republish the public and protected
> interfaces with using declarations (ignoring the fact that that cannot
> be done correctly that way if there is a function that has overloads
> some of which are public and some are protected)
>
> Now I have been continuing to think about how we could make inheritance
> of implementation easier and thereby more frequently used. A serious
> problem with public inheritance is that it exposes a derived to base
> implicit conversion.

I don't think that inheritance of implementation should be encouraged. I
see it as an unsatisfactory shortcut to achieve delegation, to which we
resort to avoid having to explicitly code delegating member functions.

I'd much prefer that some syntax was introduced to support automatic
delegation to  a class's data members.

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

brangdon@cix.co.uk (Dave Harris) wrote in message news:<memo.20011111145458.48891B@brangdon.madasafish.com>...
> I suppose I am seeing it as black-and-white. Either inheritance is
> public and provides LSP, or it isn't. Either the base class is designed
> for inheritance or it isn't. "Public explicit" is a kind of half-way
> house, almost an oxymoron. Does it really lead to good designs?

Depends. No, it doesn't enforce good designs. Yes, it can be used to
achieve good designs.

Its primary uses would be 'template typedef inheritance' (let's hope
we won't need that one) and composition/member injection (ala generic
programming.)

i.e.

template<class T> class X: public explicit Y<T, int>;

or

template<class T> class array_access
{
  typename T::value_type & operator[](long i) { return
static_cast<T*>(this)->get()[i]; }
};

template<class T> class scoped_array: public explicit
array_access<array<T> >
{
  // ...
}

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]