"All public methods should be virtual" - yes or no / pros & cons

  • Thread starter Thread starter Ken Brady
  • Start date Start date
Having read your clear example I say DBC can be implemented much,
No. It most definitely cannot. Private virtuals guarantees that the most
derived override is called once and once only when called from the base
class. Events do no such thing.
Click to expand...

The point is to have the client implement alternative behavior. That is what
an event provides. I speak of client and not of derived class since
inheritence does not apply once we choose to use an event instead of a
sub-class to achieve our goal. You can still subclass and implement the new
behavior on any class-level you choose, that is the same as with the private
virtual method.

The (base) class would switch to either the default implementation (Carl's
virtual void part_b()) or the event implementation provided by the client,
depending on whether the event were implemented or not.

If the given example is the best reason to use private virtual methods, it
is really abusing polymorphism to implement an event mechanism. I am not
saying that polymorphism and events are equivalent, I am saying that the
example provided by Carl is a good example of when you should not use
polymorphism if you do have a more natural alternative like events
(delegates in C#).

Polymorphism and inheritence go hand in hand. If you want the polymorphism
part but you do not want the inheritence then you are really saying "this
mechanism is not really suited for my needs but that's okay, I'll cripple
the part that I don't need". It is like using an integer as a boolean.
:-))))))))).

Martin.
 
The reason it damages design by contract is that it allows derived classes
to break the contract, since they can invoke their own virtual functions
without going through the public (contract-enforcing) interface.
Click to expand...

Is it not already possible for derived classes to invoke those functions
anyways. It is a function that belongs to derived afterall? For example:

class Base
{
private:
virtual void f() = 0;
};

class Derived : public Base
{
public:
void g()
{ f(); }

private: // or whatever

virtual void f()
{}

};

I don't see how whether the base class having f() as private or protected
makes any difference to Derived? Additionally, whether 'f()' is protected or
private will make no difference to non-derived classes - it will be
inaccessable.

Whether 'f()' is protected or private _will_ make a difference if any
derived class tries to call 'f()' statically ( ie.. Base::f() ). If it was
private, it would fail.

Brian
 
You seem to suggest that C++s support for private virtual functions makes
C++ less robust. Funny, I'd claim exactly the opposite.


Simple: If you don't understand it, don't use it and everything will be
well. If you happen to maintain somebody else's code using the private
virtual idiom it should become obvious very quickly how it works. If not,
post an appropriate question to comp.lang.c++ ;-).
I really fail to see how private virtuals hurt "industrial robustness".
Click to expand...

The general point Brandon is making is that in C++ you will easily "use" a
lot of nifty features that you do not understand without being aware of it,
it is unfornunately not a choice in many cases (no pun intended). That has
been acknowledged by the C# designers.

In the private virtual discussion, robustness may not be an issue. I would
call it "not elegant".


Every time something new comes along the established lot will say "Kid's
stuff, no gain, too slow, don't need it". And after a while we all learn to
appreciate it.

And oh (I almost forgot): "my language is better than yours".

Martin.
 
One thing that the industry needs a clean up on is Ego and Arrogance.

Look at linux for a start.
 
You call having to DUPLICATE method signitures (prototypes) as good coding?
Its to make up for the bad design in the compilers.

These days our Tools work for us not we work for them. Welcome to the REAL
world.
 
Brian said:
Is it not already possible for derived classes to invoke those
functions anyways. It is a function that belongs to derived afterall?
Click to expand...

D'oh! you're right of course.

The derived class can still break the contract for itself. Perhaps then the
only advantage to having the methods private instead of protected is to
inform the person who's writing a derived class that the method shouldn't be
called at all (except by the existing, public methods in the base class).

Mea culpa.

-cd
 
Carl Daniel said:
The derived class can still break the contract for itself. Perhaps then the
only advantage to having the methods private instead of protected is to
inform the person who's writing a derived class that the method shouldn't be
called at all (except by the existing, public methods in the base class).
Click to expand...

Perhaps.

Personally, for what little difference it actually makes in practice, I have
started using the convention that anything virtual is protected or public
(never private).

My reasoning is this:

'public' means anything that is important to anyone.
'protected' means anything that is important only to derived classes and
should not be made public.
'private' is anything that is important only to the class itself.

Because 'virtual' is always a factor for derived classes - this means (to
me) that it should be classified as protected (or public).

[The outcome of this is that when I am looking at a class interface inside a
header file, I can limit myself to either public items (if I am just using
the class) or public/protected items (if I am deriving from the class).]

I suspect this is similar to the reasoning behind how C#/java work.

Brian
 
Andreas said:
Brandon J. Van Every wrote:

Simple: If you don't understand it, don't use it and everything will
be well. If you happen to maintain somebody else's code using the
private virtual idiom it should become obvious very quickly how it
works. If not, post an appropriate question to comp.lang.c++ ;-).
I really fail to see how private virtuals hurt "industrial
robustness".
Click to expand...

Keep It Simple Stupid. If you don't understand how that affects industrial
robustness, you are a C++ tweak-head. People get paid looooooootsa money to
understand each and every one of C++'s weirdnesses.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 
.. said:
One thing that the industry needs a clean up on is Ego and Arrogance.
Why?

Look at linux for a start.
Click to expand...

Is that an example of more or less ego and arrogance? And is that resulting
in better or worse something or other?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 
Carl Daniel [VC++ MVP]
It's clearly simpler, and it may well be easier to understand (personally I
din't think so, but then I'm from a C++ background).

The significance of this thread though is to amplify the point that this
simplification comes with a cost: certain very valuable design idioms are
simply not possible in C# (or Java) because of the restriction on overriding
a private method.
Click to expand...

It appears later on that it doesn't actually give a valuable design
idiom, because the method can be called by the derived class anyway. I
suppose it stops it from being called by a class which is *further*
derived.

Anyway, the C++ approach has a cost too: private in C++ being not as
private as in C#/Java comes at the cost of namespace pollution. One of
the nice things about private methods etc is that whatever you call
them when you first write them, you can change that name later with
*no* impact to other classes (that aren't doing nasty reflection
things). No-one else knows about them, because they're private. (Even
the word "private" doesn't ring true with the C++ semantics, IMO.)
 
Brandon said:
Keep It Simple Stupid.
Click to expand...

Hmmm, why then aren't we still programming in (pre-VB .NET) BASIC? To me
that's much simpler than C# ;-).
If you don't understand how that affects
industrial robustness, you are a C++ tweak-head.
Click to expand...

Call me whatever you want. You still fail to demonstrate how private
virtuals make things less robust.
People get paid
looooooootsa money to understand each and every one of C++'s
weirdnesses.
Click to expand...

I've never seen such people. I'd rather say people get paid loads of money
to do proper software engineering. Yes, C++ has it's shady corners I'd
rather not have in the language but private virtuals is not one of them.
TMK, no C++ expert has ever mentioned private virtuals in this respect.

Regards,

Andreas
 
there are times when it's useful.
Name one :-).
Click to expand...

Can I just note, I wasn't trying to argue for or against private virtuals,
just noting why they're different to protected virtuals :) However, Jim
Hyslop and Herb Sutter wrote a nice article that provided a reasonable
example: http://www.cuj.com/documents/s=8000/cujcexp1812hyslop/

I actually regularly develop using both C++ and C#, I haven't especially
missed private virtuals (the times when I may have used them, attributes
have made much better alternatives). :)

n!
 
Andreas said:
Hmmm, why then aren't we still programming in (pre-VB .NET) BASIC? To
me that's much simpler than C# ;-).
Click to expand...

Lots of people *are* still programming in pre .NET VB. Languages have many
reasons for evolving other than simplicity and robustness within a domain.
C++ is clearly a kitchen sink language.
Call me whatever you want. You still fail to demonstrate how private
virtuals make things less robust.
Click to expand...

It is far more strategic than that. Any time you make a language with lotsa
tweaky special cases you can do "kewl" things with, you are increasing the
number of things that software engineers have to understand. Consequently,
you are decreasing their ability to get trained and communicate + coordinate
effectively with one another. Sheer dogpile of features will overwhelm
engineering efforts, even if each feature is individually not rocket science
to understand.
TMK, no C++ expert has ever mentioned private virtuals in this respect.
Click to expand...

The fact of even needing C++ experts such as in comp.lang.c++.moderated says
it all.

Mantra:
Forest. Trees. Forest. Trees.

And I'm not talking inheritance.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 
It is far more strategic than that. Any time you make a language with lotsa
tweaky special cases you can do "kewl" things with, you are increasing the
number of things that software engineers have to understand.
Click to expand...

I don't understand your way of thinking here. C++ has no special case for
private virtual member functions. Private means what it always do, it limits
the access to it's own class. Virtual means what it always do, it can be
overridden by derived classes. The combination is no special case. It seems
like it's C# that has a special case for the combination by not allowing it.
 
Dag Henriksson said:
I don't understand your way of thinking here. C++ has no special case for
private virtual member functions. Private means what it always do, it limits
the access to it's own class. Virtual means what it always do, it can be
overridden by derived classes. The combination is no special case. It seems
like it's C# that has a special case for the combination by not allowing it.
Click to expand...

Not at all - it's just that C#'s idea of "private" is a lot simpler
than C++'s: "Private means nothing outside the class knows it's there
at all" effectively.
 
You call having to DUPLICATE method signitures (prototypes) as good coding?
Its to make up for the bad design in the compilers.
Click to expand...

Sorry, I haven't got a clue what you're talking about. How do private
virtual functions duplicate method signatures?
These days our Tools work for us not we work for them. Welcome to the REAL
world.
Click to expand...

Well, C++ compilers have always worked for me and they still do(the
same goes for the C# compiler). I don't see how that could ever be the
other way round.

Regards,

Andreas
 
Not at all - it's just that C#'s idea of "private" is a lot simpler
than C++'s: "Private means nothing outside the class knows it's there
at all" effectively.
Click to expand...

Aha, I see. In C# public/protected/private controls visibilty, in contrast
to C++ where it controls accessibility.
 
If its private its for that class as you state, if its inherited from that
base class, its nolonger the same class so private should not be visible to
the inherited class.

Thats logic.
 
If its private its for that class as you state, if its inherited from that
base class, its nolonger the same class so private should not be visible to
the inherited class.

Thats logic.
Click to expand...

It might be logic in C#, but not in C++.
The access specifiers public/protected/private does not control visibility
in C++, only accessibility.
 
Yes because function prototypes in C are working for us, no no we are not
coding them to help the compilers bad design of not being able to check
usage.
 
Back
Top