By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,247 Members | 1,165 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,247 IT Pros & Developers. It's quick & easy.

Virtual private member functions

P: n/a
Why we need "virtual private member functions"? Why it is not an
(compile time) error?

Mar 28 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
On Mar 28, 12:50 pm, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
But why it should be a compile time error?

Mar 28 '07 #2

P: n/a
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?

Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.

Mar 28 '07 #3

P: n/a
On 28 Mar, 06:50, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"?
Because it allows you to extend classes without being afraid that you
change the interface. You could for example provide checks in the base-
class so that some invariants always are true and this can't be
circumvented by inheritance.

class Base
{
virtual int doFoo(int) = 0;

public:
int foo(int);
};

int Base::foo(int n)
{
// do checks on n
int tmp = doFoo(n);
// Check tmp
return tmp;
}

class Derived : public Base
{
virtual int doFoo(int);
};

So here we let the derived class provide all the functionality (you
cold of course make some default implementation in Base) but by always
checking the values passes to and returned from doFoo() we can make
some guarantees.

--
Erik Wikström

Mar 28 '07 #4

P: n/a
On Mar 28, 11:05 am, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?

Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?

Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.
Calling virtual private member function is anyway different from
calling non-virtual private member? virtual keyword has nothing to
do with private access specifier. right?

Mar 28 '07 #5

P: n/a
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?

Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?

Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.
This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".

On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.

--
Computational Fluid Dynamics, CSIRO (CMIS)
Melbourne, Australia

Mar 28 '07 #6

P: n/a
On 28 Mar, 08:27, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
On Mar 28, 11:05 am, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.

Calling virtual private member function is anyway different from
calling non-virtual private member?
No, consider this for example:

class Foo
{
public:
virtual void foo() { /* do stuff */ }
};

int main()
{
Foo f;
f.foo();
}

Here we call the virtual member function foo() and the same thing
happens as if the method was not virtual. The fact that the method is
private means that derived classes can't call it whenever it want,
only through the methods in the base-class that calls it (of course it
can always call on it's own implementation of the private function,
see Craig Scott's post for more on that).

Virtual only comes into play when using inheritance and only if the
derived class decides to overload the methods, consider this:

#include <iostream>

struct Base
{
virtual void foo() { std::cout << "Base\n"; }
};

struct Derived1 : public Base
{
};

struct Derived2 : public Derived1
{
void foo() { std::cout << "Derived2\n"; }
};

int main()
{
Base b;
b.foo();

std::cout << "\n";

Derived1 d1;
d1.foo();

std::cout << "\n";

Derived2 d2;
d2.foo();
}

virtual keyword has nothing to
do with private access specifier. right?
Right.

--
Erik Wikström

Mar 28 '07 #7

P: n/a
On Mar 28, 2:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.

This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".

On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
You make a valid point. protected by default makes sense. For the sake
of the OP's quest, i'm simply attempting to make a distinction between
public/protected/private accessibility and virtual functions in an
inheritance tree.

Mar 28 '07 #8

P: n/a
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.

This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".

On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
Yes, I agree, but how come derived class can ever see private parts of
base class. Is this right?

Mar 29 '07 #9

P: n/a
On Mar 29, 3:17 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.
This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".
On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.

Yes, I agree, but how come derived class can ever see private parts of
base class. Is this right?
What makes you beleive that a derived object needs to "see" the
private parts of its base counterpart? Consider that the base is
constructed before the derived entity is completed. The derived object
at runtime can only access the base's public/protected interface -
that interface itself has access to anything inside that part of the
object.

If what confuses you is how the virtual mechanism is generated (in
your case probably a v-table) then that occurs regardless of
accessability assigned to the virtual functions and regardless of
whether the function is overridden at all.
Mar 29 '07 #10

P: n/a
On Mar 29, 9:17 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.comwrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.
This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".
On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
I don't think you really need a "default". Design should decide
in each case.

Most of the time, the virtual functions will be pure virtual in
an abstract base class. In such cases, if the class has
invariants, or defines any sort of contract, the functions
should probably be private. Otherwise (e.g. inversion of call
situations, like the visitor pattern or a callback in an
observer), there's really no point in not making them public.

When a derived class provides an implementation, logically, most
of the time, you'd want to "finalize" the function, and not
allow any further derived class de redefine it. Your
implementation is part of how you maintain your class
invariants, and allowing a further derived class to replace it
with something else means that you can no longer be sure of
enforcing your contract.
Yes, I agree, but how come derived class can ever see private parts of
base class. Is this right?
They're called access specifiers for a reason: they control
access, not visibility. There are various historical reasons
for this, and one can argue about whether it is right or wrong
from a theorectical point of view, but it works well in
practice.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Mar 29 '07 #11

P: n/a
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Google for "template method design pattern" to see a very practical
use of virtual private functions.

Mar 29 '07 #12

P: n/a
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.

I don't think you really need a "default". Design should decide
in each case.
Agreed. In the above context, by "default" I meant the choice a
designer might start with or apply when there seems no obvious choice
either way.
Most of the time, the virtual functions will be pure virtual in
an abstract base class.
This depends on the situation. Consider a (fairly common) case where
the intended design is for a base class to implement default behavior
for a "Template Method" design pattern. It might leave some pure
virtual, others with default implementations. Subclasses then override
just the pure virtual ones and then only those with default
implementations that they want to customize. Such an arrangement would
seem particularly well-suited to scientific or mathematical
applications where algorithms are often derivatives or customizations
of other similar ones.
In such cases, if the class has
invariants, or defines any sort of contract, the functions
should probably be private.
Why? If a subclass calls the base class implementation as part of its
own, the base class implementation can still test its invariants and
the subclass is responsible for ensuring those invariants are not
violated on entry to that function. This would apply to the subclass
whether it was using the base class implementation or not (ie not
violate any of the base class invariants). Whether the author of the
subclass has access to the list of invariants assumed by the base
class is another question, usually one of documentation. ;)
Otherwise (e.g. inversion of call
situations, like the visitor pattern or a callback in an
observer), there's really no point in not making them public.
Personal preference. Plenty of people argue for and against whether
having virtual functions in the public interface is good design
practice. I'll keep my nose out of that debate!

When a derived class provides an implementation, logically, most
of the time, you'd want to "finalize" the function, and not
allow any further derived class de redefine it. Your
implementation is part of how you maintain your class
invariants, and allowing a further derived class to replace it
with something else means that you can no longer be sure of
enforcing your contract.
Same as my comments earlier this post. More derived subclasses may
want to further refine the implementation. It would seem better to
implement your own subclass such that it worries about its own
invariants and those of any base classes. If anyone wants to further
subclass your own subclass and override your implementation, then they
become responsible for ensuring that all invariants of its base
classes (including your own) are enforced. C++ does not offer a way to
say "this virtual function cannot be overridden again in any further
subclass".

--
Computational Fluid Dynamics, CSIRO (CMIS)
Melbourne, Australia

Apr 2 '07 #13

P: n/a
On Apr 2, 5:43 am, "Craig Scott" <audiofana...@gmail.comwrote:
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.comwrote:
On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being calledin
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
I don't think you really need a "default". Design should decide
in each case.
Agreed. In the above context, by "default" I meant the choice a
designer might start with or apply when there seems no obvious choice
either way.
But that's a bit my point: the designer shouldn't start with a
preconceived choice. It's one of those things that requires
systematic consideration on a case by case basis. And there are
some basic rules which mean that according to the role of the
class, the "obvious" choice is different.
Most of the time, the virtual functions will be pure virtual in
an abstract base class.
This depends on the situation. Consider a (fairly common) case where
the intended design is for a base class to implement default behavior
for a "Template Method" design pattern.
The template pattern is a bit of an exception. Although it's a
good example of a case where the virtual functions would almost
certainly be private, you're right that they will often not be
pure virtual, but will provide a default implementation instead.
It might leave some pure
virtual, others with default implementations. Subclasses then override
just the pure virtual ones and then only those with default
implementations that they want to customize. Such an arrangement would
seem particularly well-suited to scientific or mathematical
applications where algorithms are often derivatives or customizations
of other similar ones.
It's also widely used in GUI's, where a virtual function is used
to obtain various display parameters, and there is almost always
a default version, which gives a default appearance.
In such cases, if the class has
invariants, or defines any sort of contract, the functions
should probably be private.
Why? If a subclass calls the base class implementation as part of its
own,
There are special cases where that's appropriate (someone
already mentionned them, I think---things like serialization),
and of course, in such cases, the virtual functions should be
protected. But such cases are the exception, not the rule.
Most of the time (I'd say over 90%), the base class will be
abstract, with only pure virtual functions, and there will be
only a single layer of inheritance.

More generally, if a class is responsible for ensuring the class
invariants (i.e. it is an implementation, and not an abstract
interface), then it doesn't want any further derived class
overriding its functions (which aren't providing "default"
behavior, but are responsible for working together to ensure the
class invariants). One can easily imagine, for example, a class
which implements an interface using the template pattern, to
allow further customization. In that case, however, the final
derived class should *not* override any of the functions of the
interface, but only those functions provided by the derived
class for customization (and the two sets of functions should be
disjoint).
the base class implementation can still test its invariants and
the subclass is responsible for ensuring those invariants are not
violated on entry to that function. This would apply to the subclass
whether it was using the base class implementation or not (ie not
violate any of the base class invariants). Whether the author of the
subclass has access to the list of invariants assumed by the base
class is another question, usually one of documentation. ;)
I'd be interested in hearing about a pattern where this actually
occurs, and where it would concretely be used.
Otherwise (e.g. inversion of call
situations, like the visitor pattern or a callback in an
observer), there's really no point in not making them public.
Personal preference. Plenty of people argue for and against whether
having virtual functions in the public interface is good design
practice. I'll keep my nose out of that debate!
I'm probably the inventor of the "virtual functions should not
be public" theory:-). Except that I invented it to solve a
particular problem (programming by contract); if that problem
doesn't exist...

Others have picked up the idea, and made an absolute of it. Or
a silver bullet. But we all know that silver bullets don't
exist.
When a derived class provides an implementation, logically, most
of the time, you'd want to "finalize" the function, and not
allow any further derived class de redefine it. Your
implementation is part of how you maintain your class
invariants, and allowing a further derived class to replace it
with something else means that you can no longer be sure of
enforcing your contract.
Same as my comments earlier this post. More derived subclasses may
want to further refine the implementation.
You mean "more derived subclasses want to violate your
invariants". As I said earlier, I'd be interested in seeing the
relevant design pattern, and knowing what problems it solves,
and when it should be used. I often hear arguments like the
above, which sum up to "more flexibility". But flexibility to
do what? And I've never heard it get beyond such vague
affermations.
It would seem better to
implement your own subclass such that it worries about its own
invariants and those of any base classes.
The only way I can ensure my invariants is to ensure that my
functions are called, and not sometimes mine, sometimes those of
some unknown further derived class. The only time those of some
further derived class can safely be used is if I design my class
for them. Typically, this means that I'm using the template
pattern in my implementation of the original base class, but in
this case, I'll define a new set of virtual functions to be
called by me, in my implementation.
If anyone wants to further
subclass your own subclass and override your implementation, then they
become responsible for ensuring that all invariants of its base
classes (including your own) are enforced.
If my invariants involve private data, it's going to be
difficult for him.
C++ does not offer a way to
say "this virtual function cannot be overridden again in any further
subclass".
I know. It would be better if there were some way to do so. On
the other hand, you'll never manage to prevent all errors with
the compiler, and there is such a thing as documentation, and
code review to ensure that it is respected.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Apr 2 '07 #14

P: n/a
* James Kanze:
>
Others have picked up the idea, and made an absolute of it. Or
a silver bullet. But we all know that silver bullets don't
exist.
James, this is the third time today that you've written nearly the same
that I've written earlier today, on my home PC. Not that I necessarily
agree with all the rest of your article. But (paranoid) are you reading
my home PC's disk? Hm, Norman has been unstable lately, grabbing 90%
CPU. And so has Thunderbird, activating Firefox for no good reason...
Now I really need a silver bullet! And a ditto gun to fire it.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Apr 2 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.