V
v4vijayakumar
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
(compile time) error?
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why we need "virtual private member functions"?
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.
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?
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.
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?
Yes, I agree, but how come derived class can ever see private parts of
base class. Is this right?
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
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.
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.
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.
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.
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!
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".
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.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.