 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Scott Meyers
Guest
|
 Posted: Sat Jul 10, 2004 11:12 am Post subject: Private derivation and the ability to redefine virtuals |
 |
|
As regular readers of this group know, I'm a slow learner. Only recently did
it occur to me that while public/protected/private can be used to limit who
can *call* a virtual function, there is no way to limit who can *redefine* it.
In Effective C++, I give an example of multiple inheritance: public from an
interface class, private from an implementation class. What follows is the
gist of the example, where we're just trying to implement a function that
returns the name of a Person preceded and succeeded by delimiters. By
default, the delimiters are [ and ].
class IPerson { // interface class
public:
virtual string name() const = 0;
};
class CPerson { // implementation class
public:
virtual const char* valueDelimOpen() const { return "["; }
virtual const char* valueDelimClose() const { return "]"; }
virtual const char* theName() const
{
// return the string whose value is
// essentially valueDelimOpen() +
// name +
// valueDelimClose()
}
private:
string name;
};
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const { return CPerson::theName(); }
private:
virtual const char* valueDelimOpen() const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose() const // closing
{ return ""; } // delimiters
};
The idea is that the derived class (MyPerson) wants to inherit implementation
from CPerson and wants to tinker with the implementation by redefining the
virtuals it inherits from the implementation class. Fine, but if we assume
that it's a design constraint that the behavior of valueDelimOpen and
valueDelimClose should never change for MyPerson, the fact that we can't
prevent further derived classes from redefining them is disturbing. That is,
any class inheriting from MyPerson can redefine valueDelimOpen and
valueDelimClose again, thus violating a MyPerson constraint.
It seems to me that the "once virtual, always virtual" rule is good for public
inheritance, but isn't necessarily valid for private inheritance, as it
prevents privately derived classes from hiding their private internals from
further derived classes. For the first time, I find myself wishing to emulate
Java's final methods or C#'s sealed methods.
Am I overlooking something, or is this a breach of encapsulation of privately
inherited implementation? And is there any way to emulate "final" or "sealed"
on a virtual function? (I know that I can prevent derivation, but I don't
want to do that. I want to prevent redefinition of privately inherited
virtuals. Yes, I can do a runtime check, but that's not prevention, that's
detection.)
Thanks,
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Antoun Kanawati
Guest
|
| Posted: Sun Jul 11, 2004 10:16 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Scott Meyers wrote:
[snip]
| Quote: | It seems to me that the "once virtual, always virtual" rule is good for public
inheritance, but isn't necessarily valid for private inheritance, as it
prevents privately derived classes from hiding their private internals from
further derived classes. For the first time, I find myself wishing to emulate
Java's final methods or C#'s sealed methods.
|
I like sealed classes and final methods, but in C++ we don't have them
yet  We have dirty tricks to seal classes.
| Quote: | Am I overlooking something, or is this a breach of encapsulation of privately
inherited implementation? And is there any way to emulate "final" or "sealed"
on a virtual function? (I know that I can prevent derivation, but I don't
want to do that. I want to prevent redefinition of privately inherited
virtuals. Yes, I can do a runtime check, but that's not prevention, that's
detection.)
|
I believe if you start by emulating "virtual", e.g.: by using stored
member function pointers or function-like objects, you should be able to
"seal" certain methods by controlling access to these members.
I cannot claim that I feel good about this approach, though; "emulating
virtual" gives me an uncomfortable feeling.
If annotation were effective for prevention, I would go for:
// *** DO NOT REDEFINE THIS VIRTUAL FUNCTION ***
// *** OR ELSE! SINCERELY, YOUR TECH-LEAD.
BTW, you can "detect" this sort of stuff before runtime by scanning
source or object files for the offensive presence, thereby giving
yourself a chance to fail the build (prevention). Again, I do not
claim that this is an easy, or pleasant, task.
On a related note: Wasn't there something called the C++ Constraint
Expression Language? Has it ever become a real piece of software?
--
Antoun Kanawati
[email]antounk.at (AT) comcast (DOT) dot.net[/email]
[remove .dot and .at before use]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Arne Adams
Guest
|
| Posted: Sun Jul 11, 2004 10:25 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
"Scott Meyers" <Usenet (AT) aristeia (DOT) com> schrieb im Newsbeitrag
news:MPG.1b5926e11230a47e989769 (AT) news (DOT) hevanet.com...
| Quote: | class CPerson { // implementation class
public:
virtual const char* valueDelimOpen() const { return "["; }
virtual const char* valueDelimClose() const { return "]"; }
virtual const char* theName() const
{
// return the string whose value is
// essentially valueDelimOpen() +
// name +
// valueDelimClose()
}
private:
string name;
};
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const { return CPerson::theName(); }
private:
virtual const char* valueDelimOpen() const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose() const // closing
{ return ""; } // delimiters
};
that it's a design constraint that the behavior of valueDelimOpen and
valueDelimClose should never change for MyPerson, the fact that we can't
prevent further derived classes from redefining them is disturbing.
|
what about this one (which is not really cute but it works):
class CPerson { // implementation class
public:
struct Protector{};
virtual const char* valueDelimOpen(Protector) const { return "["; }
virtual const char* valueDelimClose(Protector) const { return "]"; }
... rest as before
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
.. same as before
private:
virtual const char* valueDelimOpen(Protector) const
{ return ""; }
virtual const char* valueDelimClose(Protector) const
{ return ""; }
};
test whether Protector protects:
class YourPerson:public MyPerson
{
private:
virtual const char* valueDelimOpen(Protector) const // error C2247 with
VC7.1
{ return ""; }
};
--
Regards,
Arne
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Sun Jul 11, 2004 4:43 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Scott Meyers <Usenet (AT) aristeia (DOT) com> writes:
| Quote: | As regular readers of this group know, I'm a slow learner. Only recently did
it occur to me that while public/protected/private can be used to limit who
can *call* a virtual function, there is no way to limit who can
*redefine* it.
|
I think you can prevent descendents of a class which derives
privately from overriding a virtual function, see below.
| Quote: |
In Effective C++, I give an example of multiple inheritance: public from an
interface class, private from an implementation class. What follows is the
gist of the example, where we're just trying to implement a function that
returns the name of a Person preceded and succeeded by delimiters. By
default, the delimiters are [ and ].
class IPerson { // interface class
public:
virtual string name() const = 0;
};
class CPerson { // implementation class
public:
virtual const char* valueDelimOpen() const { return "["; }
virtual const char* valueDelimClose() const { return "]"; }
|
Make CPerson declare a protected local type, and make the functions you don't
want overridable take it as a parameter:
protected:
struct preventer{};
public:
virtual const char* valueDelimOpen(preventer= preventer()) const { return "["; }
virtual const char* valueDelimClose(preventer= preventer()) const { return "]"; }
virtual const char* theName() const
This doesn't prevent overriding in the normal case, but I think it
prevents overriding after IPerson is derived from privately.
| Quote: | virtual const char* theName() const
{
// return the string whose value is
// essentially valueDelimOpen() +
// name +
// valueDelimClose()
}
private:
string name;
};
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const { return CPerson::theName(); }
private:
virtual const char* valueDelimOpen() const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose() const // closing
{ return ""; } // delimiters
};
The idea is that the derived class (MyPerson) wants to inherit implementation
from CPerson and wants to tinker with the implementation by redefining the
virtuals it inherits from the implementation class. Fine, but if we assume
that it's a design constraint that the behavior of valueDelimOpen and
valueDelimClose should never change for MyPerson, the fact that we can't
prevent further derived classes from redefining them is disturbing. That is,
any class inheriting from MyPerson can redefine valueDelimOpen and
valueDelimClose again, thus violating a MyPerson constraint.
It seems to me that the "once virtual, always virtual" rule is good for public
inheritance, but isn't necessarily valid for private inheritance, as it
prevents privately derived classes from hiding their private internals from
further derived classes. For the first time, I find myself wishing to emulate
Java's final methods or C#'s sealed methods.
[snip] |
Using the trick above, this class decl:
class ThirdPerson:public MyPerson
{
virtual const char* valueDelimOpen(CPerson::preventer =CPerson::preventer()) const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose(CPerson::preventer =CPerson::preventer()) const // closing
{ return ""; } // delimiters
};
results in errors like these:
meyers_10_jul_04.cc:13: error: `struct CPerson::preventer' is protected
meyers_10_jul_04.cc:45: error: within this context
If preventer isn't qualified, it's still an error.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Antoun Kanawati
Guest
|
| Posted: Sun Jul 11, 2004 11:55 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Arne Adams wrote:
| Quote: | what about this one (which is not really cute but it works):
class CPerson { // implementation class
public:
protected: //correction
struct Protector{};
public:// end-correction
virtual const char* valueDelimOpen(Protector) const { return "["; }
virtual const char* valueDelimClose(Protector) const { return "]"; }
.. rest as before
class MyPerson: public IPerson, private CPerson {
public:
.. same as before
private:
virtual const char* valueDelimOpen(Protector) const{ return ""; }
virtual const char* valueDelimClose(Protector) const { return ""; }
};
test whether Protector protects:
class YourPerson:public MyPerson
{
private:
virtual const char* valueDelimOpen(Protector) const // error C2247 with
VC7.1
{ return ""; }
};
|
Almost right. As shown, a CPerson::Protector would remove the compile
error. However, if you change the visibility of CPerson::Protector
to protected, the class YourPerson won't be able to use it.
--
Antoun Kanawati
[email]antounk.at (AT) comcast (DOT) dot.net[/email]
[remove .dot and .at before use]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Mon Jul 12, 2004 12:17 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
"Arne Adams" <arne.adams (AT) t-online (DOT) de> writes:
| Quote: | "Scott Meyers" <Usenet (AT) aristeia (DOT) com> schrieb im Newsbeitrag
news:MPG.1b5926e11230a47e989769 (AT) news (DOT) hevanet.com...
class CPerson { // implementation class
public:
virtual const char* valueDelimOpen() const { return "["; }
virtual const char* valueDelimClose() const { return "]"; }
virtual const char* theName() const
{
// return the string whose value is
// essentially valueDelimOpen() +
// name +
// valueDelimClose()
}
private:
string name;
};
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const { return CPerson::theName(); }
private:
virtual const char* valueDelimOpen() const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose() const // closing
{ return ""; } // delimiters
};
that it's a design constraint that the behavior of valueDelimOpen and
valueDelimClose should never change for MyPerson, the fact that we can't
prevent further derived classes from redefining them is disturbing.
what about this one (which is not really cute but it works):
class CPerson { // implementation class
public:
struct Protector{};
virtual const char* valueDelimOpen(Protector) const { return "["; }
virtual const char* valueDelimClose(Protector) const { return "]"; }
.. rest as before
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
.. same as before
private:
virtual const char* valueDelimOpen(Protector) const
{ return ""; }
virtual const char* valueDelimClose(Protector) const
{ return ""; }
};
test whether Protector protects:
class YourPerson:public MyPerson
{
private:
virtual const char* valueDelimOpen(Protector) const //
error C2247 with
|
Protector needs to be protected. :-)
If it is public, this:
virtual const char* valueDelimOpen(CPerson::Protector) const
compiles.
| Quote: | { return ""; }
};
[snip] |
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Mon Jul 12, 2004 11:22 am Post subject: CCEL (Was: Private derivation and the ability to redefine vi |
|
|
On 11 Jul 2004 06:16:40 -0400, Antoun Kanawati wrote:
| Quote: | On a related note: Wasn't there something called the C++ Constraint
Expression Language? Has it ever become a real piece of software?
|
Work on CCEL pretty much ended when I left Brown in 1993. One company
(TakeFive Software, now apparently a part of Wind River) looked into
commercializing it, but my understanding is that nothing ever came of that.
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Mon Jul 12, 2004 11:23 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Quoting myself:
| Quote: | while public/protected/private can be used to limit who
can *call* a virtual function, there is no way to limit who can *redefine* it.
|
It has now been demonstrated that a base class can design virtual functions
to allow derived classes to prevent further redefinition of the virtuals.
Clever (and unknown to me -- thanks for sharing). But virtual functions
are typically not set up that way, so, in practice, privately inheriting
most virtual functions offers the privately inheriting class no way to
prevent further derived classes from further redefining the inherited
virtuals, right?
| Quote: | It seems to me that the "once virtual, always virtual" rule is good for public
inheritance, but isn't necessarily valid for private inheritance, as it
prevents privately derived classes from hiding their private internals from
further derived classes. For the first time, I find myself wishing to emulate
Java's final methods or C#'s sealed methods.
Am I overlooking something, or is this a breach of encapsulation of privately
inherited implementation?
|
Thoughts on this?
Thanks,
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Mon Jul 12, 2004 9:27 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
In article <MPG.1b5bc6d9e03c5d9198976d (AT) news (DOT) hevanet.com>, Scott Meyers
<Usenet (AT) aristeia (DOT) com> writes
| Quote: | It has now been demonstrated that a base class can design virtual functions
to allow derived classes to prevent further redefinition of the virtuals.
Clever (and unknown to me -- thanks for sharing). But virtual functions
are typically not set up that way, so, in practice, privately inheriting
most virtual functions offers the privately inheriting class no way to
prevent further derived classes from further redefining the inherited
virtuals, right?
|
Can you produce any real world code where this matters? Or is the issue
that private inheritance should be an implementation detail but that as
we have it today it can quietly make functions in the derived class
virtual because they coincidentally have the same name as those in a
private base?
That raises a design issue; under what circumstances should a
polymorphic class (one with virtual functions) be used as a private
base? My gut reaction is 'never'. But I cannot remember seeing that
stated in any book that I have read (but perhaps my memory is going:-)
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Dimov
Guest
|
| Posted: Mon Jul 12, 2004 9:28 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Scott Meyers <Usenet (AT) aristeia (DOT) com> wrote
| Quote: | As regular readers of this group know, I'm a slow learner. Only recently did
it occur to me that while public/protected/private can be used to limit who
can *call* a virtual function, there is no way to limit who can *redefine* it.
In Effective C++, I give an example of multiple inheritance: public from an
interface class, private from an implementation class. What follows is the
gist of the example, where we're just trying to implement a function that
returns the name of a Person preceded and succeeded by delimiters. By
default, the delimiters are [ and ].
class IPerson { // interface class
public:
virtual string name() const = 0;
};
class CPerson { // implementation class
public:
virtual const char* valueDelimOpen() const { return "["; }
virtual const char* valueDelimClose() const { return "]"; }
virtual const char* theName() const
{
// return the string whose value is
// essentially valueDelimOpen() +
// name +
// valueDelimClose()
}
private:
string name;
};
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const { return CPerson::theName(); }
private:
virtual const char* valueDelimOpen() const // customize the
{ return ""; } // opening and
virtual const char* valueDelimClose() const // closing
{ return ""; } // delimiters
};
The idea is that the derived class (MyPerson) wants to inherit implementation
from CPerson and wants to tinker with the implementation by redefining the
virtuals it inherits from the implementation class. Fine, but if we assume
that it's a design constraint that the behavior of valueDelimOpen and
valueDelimClose should never change for MyPerson, the fact that we can't
prevent further derived classes from redefining them is disturbing. That is,
any class inheriting from MyPerson can redefine valueDelimOpen and
valueDelimClose again, thus violating a MyPerson constraint.
|
If you never put virtual functions in non-interface classes, you'll
never encounter this problem.
class MyPerson: public IPerson, // class combining interface and
private CPerson { // implementation
public:
virtual string name() const
{
return CPerson::valueDelimOpen() + CPerson::name() +
CPerson::valueDelimClose();
}
};
class MyPerson2: public IPerson,
private CPerson {
public:
virtual string name() const { return "{" + CPerson::name() + "}"; }
};
This is, of course, oversimplified. But so is your example. It even
allows
class MyPerson3: public IPerson, private CPerson {
public:
MyPerson3(): CPerson("[", "]") {}
virtual string name() const { return CPerson::theName(); }
};
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx
Guest
|
| Posted: Mon Jul 12, 2004 10:13 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Scott Meyers <Usenet (AT) aristeia (DOT) com> wrote
| Quote: | Am I overlooking something, or is this a breach of encapsulation of privately
inherited implementation?
|
There is a violation of encapsulation here, but I don't think it's
where you think it is. :-)
Consider:
class B {
public:
virtual void foo();
};
class D: public B {
public:
void bar() { foo(); }
};
Implicitly, D::bar() is calling this->foo(). That is, it is calling a
virtual function through a pointer to an object of *unknown* dynamic
type (the dynamic type of *this could turn out to be D or anything
derived from D). Depending on some particular implementation of that
virtual function -- i.e. assuming you know the dynamic type of *this
-- violates encapsulation. Don't do that.
The encapsulation issue in this situation doen't have anything to do
with access control; it's completely a matter of what you're allowed
to assume about virtual functions called through a pointer or
reference.
OK...back to real life. You've got a real requirement: class MyPerson
*wants* to depend on the dynamic type of an object derived from
CPerson. You can accomplish that safely enough by using containment
instead of inheritance to give MyPerson a CPerson-derived sub-object.
class MyCPerson: public CPerson {
// override virtual functions as needed
};
class MyPerson: public IPerson {
private:
MyCPerson mImpl;
public:
string name() const { return mIpml.theName(); }
};
Now MyPerson knows the exact type of its CPerson-derived subobject and
can actually guarantee that to others. (If the implementation of
MyCPerson is really just an implementation detail of MyPerson, it
wouldn't hurt to make MyCPerson a private member type of MyPerson.)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Mon Jul 12, 2004 10:16 pm Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Scott Meyers <Usenet (AT) aristeia (DOT) com> writes:
| Quote: | Quoting myself:
while public/protected/private can be used to limit who
can *call* a virtual function, there is no way to limit who can *redefine* it.
It has now been demonstrated that a base class can design virtual functions
to allow derived classes to prevent further redefinition of the virtuals.
Clever (and unknown to me -- thanks for sharing). But virtual functions
are typically not set up that way, so, in practice, privately inheriting
most virtual functions offers the privately inheriting class no way to
prevent further derived classes from further redefining the inherited
virtuals, right?
It seems to me that the "once virtual, always virtual" rule is good for public
inheritance, but isn't necessarily valid for private inheritance, as it
prevents privately derived classes from hiding their private internals from
further derived classes. For the first time, I find myself wishing to emulate
Java's final methods or C#'s sealed methods.
Am I overlooking something, or is this a breach of encapsulation of privately
inherited implementation?
|
It allows a function to be overriden in a way that does not satisfy
the base classes' invariant. I don't know if this is a breach of
encapsulation or not, but whatever it is called, it is bad.
It's better to make virtual functions in the base class protected, so
that the user of the class is required to call a non-virtual
function (which therefor cannot be over-ridden) which can attempt
to enforce the pre-conditions, post-conditions, of the function,
and the type's invariant. This doesn't prevent the function from
being overriden, but it does allow constraints on the behavior of
the overrrider.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Stefan Heinzmann
Guest
|
| Posted: Tue Jul 13, 2004 10:52 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
johnchx wrote:
[...]
| Quote: | Consider:
class B {
public:
virtual void foo();
};
class D: public B {
public:
void bar() { foo(); }
};
Implicitly, D::bar() is calling this->foo(). That is, it is calling a
virtual function through a pointer to an object of *unknown* dynamic
type (the dynamic type of *this could turn out to be D or anything
derived from D). Depending on some particular implementation of that
virtual function -- i.e. assuming you know the dynamic type of *this
-- violates encapsulation. Don't do that.
|
I don't understand. You're just relying on foo() to obey its contract,
no matter which concrete class has implemented it. In other words, you
don *not* depend on the dynamic type. The nature of dynamic polymorphism
is at work here. Why does that violate encapsulation?
--
Cheers
Stefan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Stefan Heinzmann
Guest
|
| Posted: Tue Jul 13, 2004 10:54 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
Francis Glassborow wrote:
[...]
| Quote: | That raises a design issue; under what circumstances should a
polymorphic class (one with virtual functions) be used as a private
base? My gut reaction is 'never'. But I cannot remember seeing that
stated in any book that I have read (but perhaps my memory is going:-)
|
Whenever you would ordinarily use a member, except that you need to
implement (override) a virtual function. The template method pattern is
a case when this occurs.
But maybe you're really saying that template methods are considered
harmful, too.
--
Cheers
Stefan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Tue Jul 13, 2004 10:59 am Post subject: Re: Private derivation and the ability to redefine virtuals |
|
|
On 12 Jul 2004 17:27:25 -0400, Francis Glassborow wrote:
| Quote: | Can you produce any real world code where this matters? Or is the issue
that private inheritance should be an implementation detail but that as
we have it today it can quietly make functions in the derived class
virtual because they coincidentally have the same name as those in a
private base?
|
No, it's that private inheritance should be an implementation detail, but
there is no way for a privately derived class to prevent futher
(potentially publically) derived classes from messing with how parts of its
implementation are implemented.
| Quote: | That raises a design issue; under what circumstances should a
polymorphic class (one with virtual functions) be used as a private
base? My gut reaction is 'never'. But I cannot remember seeing that
stated in any book that I have read (but perhaps my memory is going:-)
|
What is the basis for this gut reaction? You're suggesting that virtual
functions are never useful in conjunction with private inheritance. Why
not?
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
