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

Carl Daniel [VC++ MVP]
1/27/2004 7:44:42 AM

[quoted text, click to view]

A private method most certainly CAN be overridden in a derived class. It
simply can'y be CALLED from outside the class where it's first declared.

In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and inforce
the invariants of the class's interface (look up "design by contract" if
that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the
virtual methods to tune the behavior of the class, but since only the base
class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring
that there are no holes in the invariant checking).

-cd

Carl Daniel [VC++ MVP]
1/27/2004 8:56:47 AM

[quoted text, click to view]

In C++. I failed to notice that this was cross-posted to the C# group as
well. More's the pitty for C# - it's a valuable idiom that they've ruled
out (Java made the same mistake).

-cd

Ken Brady
1/27/2004 9:04:43 AM

I'm on a team building some class libraries to be used by many other
projects.

Some members of our team insist that "All public methods should be virtual"
just in case "anything needs to be changed". This is very much against my
instincts. Can anyone offer some solid design guidelines for me?

Thanks in advance....

Frank Oquendo
1/27/2004 9:30:46 AM

[quoted text, click to view]

A private method cannot be derived so what's the point of marking it
virtual?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Carl Daniel [VC++ MVP]
1/27/2004 10:28:23 AM

[quoted text, click to view]

The problem is that it makes it impossible to use design by contract and
guarantee that the contract is not violated. If you don't want to use
design by contract, then you'll never realize the loss of that ability.

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.

[quoted text, click to view]

The fact that a method is virtual means that a derived class can replace it.
The fact that a method is private means that only the declaring class can
access it. The two are completely orthogonal concepts - why tie them
together artificially?

-cd

Carl Daniel [VC++ MVP]
1/27/2004 10:29:57 AM

[quoted text, click to view]

protected means they're accessible in derived classes. It has no bearing
(in C++) as to whether a declaration in a deriving class overrides a
(virtual function) declaration in a base class.

-cd

Frank Oquendo
1/27/2004 10:44:39 AM

[quoted text, click to view]

Not in C#. Private makes a member accessible to the defining class alone.
Protected makes it accessible to derived classes.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Frank Oquendo
1/27/2004 10:47:01 AM

[quoted text, click to view]

Private is just that: private to the defining type. It works the same way in
Java. It also makes the class design quite obvious as members intended for
use in derived classes are marked protected, not private. I find that level
of granularity to be quite straightforward and very useful.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Frank Oquendo
1/27/2004 11:18:52 AM

[quoted text, click to view]

I fail to see what's so terrible about it. Marking a member as protected
makes it accessible to derived classes thus giving a type's author the
ability to retain complete control over a private member.

I see the ability override private members as a problem, not a feature.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Frank Oquendo
1/27/2004 11:29:56 AM

[quoted text, click to view]

Because they're unnecessary thanks to the protected keyword. Why support two
ways to override a member when one access modifier has semantics the other
does not?

Considering nothing is virtual by default in C#, it makes perfect sense to
use protected virtual instead of private virtual.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Carl Daniel [VC++ MVP]
1/27/2004 11:37:18 AM

[quoted text, click to view]

Imagine that you have a class (C++ syntax):

class C
{
public:
virtual ~C() {}
void process()
{
part_a();
part_b();
part_c();
}

private:
void part_a() {}
virtual void part_b() {}
void part_c() {}
};

This class is clearly designed to be used polymorphically: the virtual
destructor and virtual part_b indicate this.

How is a class used polymorphically? Through a pointer (or reference) to a
base class. Using a pointer to the base class (C), only the process()
method is available - that's the public interface of C.

A derived class can override part_b, but it cannot invoke any of the parts
of process (part_a, part_b, part_c) independently.

Now, imagine that part_a() validates that the object is in a coherent state
and logs the start of process(), while part_c re-validates that the object
is in a coherent state, logs the end of process() and frees resources
acquired in part_a. (Clearly there would be exception safety issues to deal
with, but that's independent of this example).

By having part_b private, a derived class can replace the implementation of
part_b, but cannot ever call it without going through process() - going
through process enforces the invariants of the class:

- The object is in a valid state before the operation
- The start of all operations is logged
- The end of all operations is logged
- The object is in a valid state after the operation

This general pattern is called "Design By Contract" (DBC). C++ lets you
implement and enforce DBC directly. C# and Java prohibit you from builing
an enforceable DBC. Of course, you can create the same mechanisms in C#,
but you can't ensure that they'll be used. If part_b where public or
protected (as required in C#/Java), any other method of a class overriding
part_b could invoke part_b directly thus skipping the invariant checks.

[quoted text, click to view]

If you can't override a private member then they're tied together.

-cd

Carl Daniel [VC++ MVP]
1/27/2004 11:40:35 AM

[quoted text, click to view]

See the example I just posted elsewhere in this thread. This is actually a
very useful design pattern - not at all esoteric once you understand it.

-cd

Carl Daniel [VC++ MVP]
1/27/2004 11:44:30 AM

[quoted text, click to view]

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.

-cd

100
1/27/2004 11:44:32 AM

Carl,
C# doesn't support private and virtual methods.

B\rgds
100

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
[quoted text, click to view]

Brandon J. Van Every
1/27/2004 12:49:02 PM

[quoted text, click to view]

It *is* esoteric, and I would wager that the C# language designers chose
simplicity in the interest of industrial robustness. "Industrial
robustness" in the real world means simplifying things so that the vast
majority of average programmers understand what's going on. C++ is a very
tweaky language with lotsa weird cases. C#, philosophically, is clearly an
attempt to clean up C++'s mess.

This observation may be lost on hardcore C++ programmers, and that is
precisely the point. In the long haul, C# will replace C++ for an awful lot
of application programming tasks. It has already happened at Microsoft and
it's only a matter of time for it to happen with the vast majority of
Windows development.

--
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.

Frank Oquendo
1/27/2004 12:58:20 PM

[quoted text, click to view]

I don't get it. Can you show me an example?

[quoted text, click to view]

They're not tied together at all. The accessibility of a member and the
ability to override that member are controlled through two separate
mechanisms.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Eric Gunnerson [MS]
1/27/2004 1:16:19 PM

I was going to write a response to this, but Martin said everything I was
going to say, so I'll just say "what Martin said..."

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
[quoted text, click to view]

n!
1/27/2004 3:09:22 PM

[quoted text, click to view]

FWIW the compiler will emit an error if you try to declare a new virtual
method within a sealed class (it will also give a warning about new
protected methods in a sealed class).

n!

TT (Tom Tempelaere)
1/27/2004 3:14:35 PM

[quoted text, click to view]

Mmmm.

I prefer the statement, "all virtual functions should be private", or the
milder "all virtual functions should at least be protected". That does not
include the destructor.

But that does not rule out public virtual functions.

Only functions that were designed to be virtual, should be virtual.

Tom.

discussion NO[at]SPAM discussion.microsoft.com
1/27/2004 3:36:45 PM

If you plan on them to be derived from then yes obviously.

If its a sealed class, then its pointless and the compiler (if it doesnt)
should prevent having virtuals in a sealed class.

[quoted text, click to view]

Dag Henriksson
1/27/2004 3:59:38 PM

"Ken Brady" <Kenneth.Brady@thomson.com> skrev i meddelandet
news:O$E2E6N5DHA.1948@TK2MSFTNGP12.phx.gbl...
[quoted text, click to view]

In fact, most experts think the opposite: "No public member functions should
be virtual".

A class exposes two interfaces, a calling interface (public functions) and a
derivation interface (virtual functions). They have different purpose and
different users and should be separate.

--
Dag Henriksson

Magnus Lidbom
1/27/2004 4:02:16 PM

There are very good reasons for not making a method virtual unless it needs
to be. That's why virtual is not the default in C#.
Here's Anders Hejlsberg's( the lead C# architect ) take:
http://www.artima.com/intv/nonvirtual.html

/Magnus Lidbom

[quoted text, click to view]

discussion NO[at]SPAM discussion.microsoft.com
1/27/2004 4:11:45 PM

Not public no, protected only.should be virtual in my view.

Does other languages prevent PUBLIC virtuals and only allow protected
virtuals?

[quoted text, click to view]

TT (Tom Tempelaere)
1/27/2004 4:17:13 PM

[quoted text, click to view]

That is a very weird decision, and I would like to hear the rationale behind
that.

Tom.

[quoted text, click to view]

Dag Henriksson
1/27/2004 4:20:35 PM

<discussion@discussion.microsoft.com> skrev i meddelandet
news:OgE4wbO5DHA.2056@TK2MSFTNGP10.phx.gbl...

[quoted text, click to view]

I prefer ususally 'private virtual', and I only use 'protected virtual' if I
have a good reason to.

--
Dag Henriksson

Carl Daniel [VC++ MVP]
1/27/2004 4:42:46 PM

[quoted text, click to view]

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

Miha Markic
1/27/2004 4:55:35 PM

Hi Carl,

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
[quoted text, click to view]

Not in C#. It can't be even declared as private virtual.
Or did I miss the meaning of your post?

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Magnus Lidbom
1/27/2004 4:58:16 PM

Be aware that this thread is cross posted across newsgroups where
the topical languages have different sematics on virtual private methods.
In C# it's disallowed. I dont know why. The code below fails to compile with
the error: "virtual or abstract members cannot be private"

namespace CSharp
{
public class Base
{
private virtual void Test(){}
}

public abstract class Child : Base
{
private override void Test(){}
}
}

Regards /Magnus Lidbom

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
[quoted text, click to view]

Dag Henriksson
1/27/2004 5:01:19 PM

"Frank Oquendo" <franko@acadxpin.com> skrev i meddelandet
news:OHqVAqO5DHA.2392@TK2MSFTNGP10.phx.gbl...
[quoted text, click to view]

Maybe not in C#, but it certainly can in C++ (this thread is cross-posted to
both groups).

--
Dag Henriksson

Miha Markic
1/27/2004 5:29:38 PM

Hi TT,

I guess because private is private to class and not only to outside world.
It makes sense to me..coming from C#.

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

"TT (Tom Tempelaere)" <_N_OSPAMtiti____@hotmail.comMAPSO_N_> wrote in
message news:dawRb.7954$EZ6.309387@phobos.telenet-ops.be...
[quoted text, click to view]

Magnus Lidbom
1/27/2004 6:09:44 PM

[quoted text, click to view]

In this case it's important to be clear about what it is that is private.
Certainly private should mean that no other class may access the member.
Whether it should mean that you can't override it if it's declared virtual
is another matter altogether. There are many situations where private
virtuals as implemented in C++ are appropriate. I too would like to know why
they are prohibited in C#.

/Magnus Lidbom

<snip>

[quoted text, click to view]

n!
1/27/2004 6:23:29 PM

[quoted text, click to view]

The point about "private virtual" is that it allows child classes to
override the method but not call it, if the same method is defined
'protected virtual' then a derived class *can* call it. Whilst it may seem
esoteric, there are times when it's useful. Though TBH I've never needed
private virtual in C# so far.

n!

Brian Ross
1/27/2004 6:26:05 PM

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
[quoted text, click to view]

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

<.>
1/27/2004 7:31:14 PM

protected means they are visible in inherited classes, wtf good is a private
declared virtual when u cant override them?

[quoted text, click to view]

Martin Maat
1/27/2004 7:32:23 PM

Ken,

[quoted text, click to view]

They are missing the point of object orientation. The first and foremost
benefit is not "ultimate" flexibility", neither is is re-use. The main
benefits are control of complexity; 1:1 mapping of the real world to a model
and comprehensiveness.

First, virtual methods do not come free, they perform worse than non-virtual
methods. Now this may be an issue and it may not, depending on the kind of
application and the way the methods are used.

Another thing. If something is declared virtual, that is a statement on the
part of the designer. It implies some generic behavior that may need to be
altered somehow for any derived.class in order to obtain the desired
behavior. It helps the developer understand the problem domain. Declaring
everything virtual is bad because the developer will wonder how he should
deal with the method in e derived class. Must he override it? Must he call
the inherited implementation? Before or after his own actions? Can he leave
it like it is? If I were that developer and I had been thinking this over,
trying to understand the purpose of a particular virtual method not
understanding how to deal with it and I finally went go to the designer of
the base class and I would ask why and he would say "For no particular
reason, I just couldn't be bothered thinking too hard about the consequences
of sealing it so I left it all open for you, providing ultimate flexibility,
so you can do the thinking I could not be bothered with, aren't you happy?"
Then I would not be happy.

Imagine every public method of a fairly complex class being virtual. Most of
them will implement fixed behavior that is not supposed to be overridden. It
would only invite developers to screw things up and they would not
understand what is expected of them.

Finally, if at some point "something needs to be changed" and polymorphism
would be the answer, then that would be the right moment to open the base
classes source and change the declaration for the particular method to
protected (not public, heaven forbid).

I read the discussion on private virtual methods too. While some languages
may technically allow them they don't make sense. In Delphi for instance you
can declare both the base class's virtual methods and the overrided derived
class's method private but that only compiles as long as both the base class
and the derived class are in the same source file. Once the derived class in
in a different source file, all the base class's private methods are
invisible and the project won't compile. Needless to say that little
projects have all classes declared in the same source file. Since it only
works if you put everything together or make everything friend with
everything else it is absolutely pointless because you can in those
situations access anything in your base class from anywhere, it is as good
as putting everything in the same class right away and not derive at all.

So the boys are wrong, you are right. Rub it in.

Martin.

<.>
1/27/2004 7:34:43 PM

I wont be buying your product then as its gona perform like the shit with
everything virtual for no damn good reason.

[quoted text, click to view]

Jon Skeet [C# MVP]
1/27/2004 7:38:45 PM

Carl Daniel [VC++ MVP]
[quoted text, click to view]

That may be what private means in C++, but in C# it's much simpler:
private means that the member is in no way visible to any other types
(outside reflection, of course). This is a much simpler view of the
world, IMO, and easier to understand.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet

Brian Ross
1/27/2004 7:59:41 PM

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
[quoted text, click to view]

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

Martin Maat [EBL]
1/27/2004 8:35:17 PM

[quoted text, click to view]

Okay, that makes sense. Technically that is.

[quoted text, click to view]

Name one :-).

I am serious, I have been giving this some thought just now but I cannot
come up with a sensible reason to do this. It makes me think of Tommy Cooper
("Pick a card, any card... No, not that one!"). Here's a method, you can use
it.. No you can't!.

Basically, it is an abstract interface with a default implementation (don't
these words make your brain turn?). The "benefit" would be that you do not
force the user to implement it as with abstract methods and you keep the
possibility of creating an instance of the base class.

I don't like it. Since the method's implementation has no generic purpose it
should not be visible. It should be totally encapsulated. The need for an
abstract interface with the same signature stands apart from the base
class's private implementation. The abstract method should therefore be
declared separately.

Whenever private virtual seems to apply, it seems to me it is only abusing
coincidentially matching method signatures. You need some implementation in
your base class on one hand and you need some abstract method to put derived
classes on the right track on the other hand, the signatures match and you
go like "Hey... I can make that one method.". Yes, you can, but it doesn't
make sense to do so, it is only confusing.

Martin.

Brandon J. Van Every
1/27/2004 9:19:35 PM

[quoted text, click to view]

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.

Brandon J. Van Every
1/27/2004 9:22:18 PM

[quoted text, click to view]

Why?

[quoted text, click to view]

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.

Martin Maat [EBL]
1/27/2004 9:45:02 PM

[quoted text, click to view]

You claim that C++ has this wonderful ability that C# and other OO-languages
lack. Having read your clear example I say DBC can be implemented much, much
nicer and cleaner using events because that is precisely what it is. The
base class provides a way to plug-in client-provided logic. Now C++ does not
support that natively so some horrible hack like a private virtual method
was used to achieve this. I am willing to call the solution "creative" and I
respect the work of the pioneers that started the programming industry as we
know it. Fortunately, we don't have to do it that way anymore these days
:-).

Martin.

Magnus Lidbom
1/27/2004 10:04:11 PM

[quoted text, click to view]

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.

<snip>

/Magnus Lidbom

Andreas Huber
1/27/2004 10:36:55 PM

[quoted text, click to view]

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

[quoted text, click to view]

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".

Regards,

Andreas

TT (Tom Tempelaere)
1/27/2004 11:17:03 PM

[quoted text, click to view]

DBC (Design By Contract). Public non-virtual interface (interface), private
virtual interface (implementation). The public interface enforces pre and
post conditions, and delegates implementation to the private virtual
implementation.

Tom.

Martin Maat [EBL]
1/28/2004 12:21:47 AM

[quoted text, click to view]

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.

Martin Maat [EBL]
1/28/2004 12:46:32 AM

[quoted text, click to view]

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.

<.>
1/28/2004 12:48:04 AM

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

Look at linux for a start.

"Brandon J. Van Every" <reverse it com dot indiegamedesign at vanevery>
[quoted text, click to view]

<.>
1/28/2004 12:49:14 AM

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.

[quoted text, click to view]

Brandon J. Van Every
1/28/2004 4:00:26 AM

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

ah2003 NO[at]SPAM gmx.net
1/28/2004 4:44:04 AM

[quoted text, click to view]

Sorry, I haven't got a clue what you're talking about. How do private
virtual functions duplicate method signatures?

[quoted text, click to view]

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,

Carl Daniel [VC++ MVP]
1/28/2004 7:54:19 AM

[quoted text, click to view]

The C++ rule that name lookup occurs before access checks is a two-edged
sword. The reason it's done that way is to avoid silent breaking-changes to
derived classes when the public/private-ness of a base class function is
changed.

class A
{
public:
void f(int);
private:
void f(double);
};

class B : public A
{
public:
void g() { f(1.0); } // illegal under C++ rules
};

If access checks were performed before name lookup/overload resolution, the
call in B::g() would bind to f(int). Subsequently changing A::f(double) to
public (or protected) would then silently change the behavior of B::g()
since it would now bind to f(double). In the above example, C++'s rampant
implicit conversion rules conspire to make the situation more difficult as
well.

The flip-side is as you say: in Java/.NET, private parts are more truly
private.

This is definitely an area where C++ and C# are different in subtle ways.
:)
-cd

Jon Skeet [C# MVP]
1/28/2004 8:10:19 AM

Carl Daniel [VC++ MVP]
[quoted text, click to view]

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.)

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet

Andreas Huber
1/28/2004 9:13:46 AM

[quoted text, click to view]

Hmmm, why then aren't we still programming in (pre-VB .NET) BASIC? To me
that's much simpler than C# ;-).

[quoted text, click to view]

Call me whatever you want. You still fail to demonstrate how private
virtuals make things less robust.

[quoted text, click to view]

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

n!
1/28/2004 10:29:49 AM

[quoted text, click to view]

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!

Jon Skeet [C# MVP]
1/28/2004 12:38:07 PM

[quoted text, click to view]

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.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet

Dag Henriksson
1/28/2004 1:17:51 PM

"Brandon J. Van Every" <reverse it com dot indiegamedesign at vanevery>
skrev i meddelandet news:u%23f0tSZ5DHA.1052@TK2MSFTNGP12.phx.gbl...

[quoted text, click to view]

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

TT (Tom Tempelaere)
1/28/2004 1:27:56 PM

[quoted text, click to view]

That is merely an opinion. If it would not make any sense as you state, C++
language would have changed the concept.

Tom.

[quoted text, click to view]

Dag Henriksson
1/28/2004 1:47:02 PM

[quoted text, click to view]

Aha, I see. In C# public/protected/private controls visibilty, in contrast
to C++ where it controls accessibility.

--
Dag Henriksson

discussion NO[at]SPAM discussion.microsoft.com
1/28/2004 1:54:13 PM

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.

[quoted text, click to view]

Dag Henriksson
1/28/2004 1:54:34 PM

<discussion@discussion.microsoft.com> skrev i meddelandet
news:uNXBkzZ5DHA.1292@TK2MSFTNGP11.phx.gbl...
[quoted text, click to view]

It might be logic in C#, but not in C++.
The access specifiers public/protected/private does not control visibility
in C++, only accessibility.

--
Dag Henriksson

discussion NO[at]SPAM discussion.microsoft.com
1/28/2004 1:55:02 PM

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.

[quoted text, click to view]

discussion NO[at]SPAM discussion.microsoft.com
1/28/2004 1:57:56 PM

visibility and accessability are one of the same. If you cant see it you
cant do jack with it. What you cant see you cant access. Obviously.

C# doesnt have the concept of "funtion prototypes" in header files because
the compiler can take care of that, why duplicate code for every method?
That is the fault of the design of C++ compilers so we have to do the work
for it.

Function prototypes are simply a hack for a bad compiler.

[quoted text, click to view]

discussion NO[at]SPAM discussion.microsoft.com
1/28/2004 2:06:39 PM

Doesnt make any sense to have it that way.

[quoted text, click to view]

Martin Maat [EBL]
1/28/2004 2:33:32 PM

[quoted text, click to view]

Hehe, this article says it all. One C++ knoledgable person that loves the
fact that her code is smart and hard to grasp. The next developer needs to
go back to the first one before he can use the class properly. That is the
whole point, it isn't wrong but it works in a counter-intuitive way,
defeating the purpose of having these visibility layers.

Nice article.

Martin.

discussion NO[at]SPAM discussion.microsoft.com
1/28/2004 2:43:39 PM

And what language do you think will be used most in the CLI world and where
the jobs are :D C#

"TT (Tom Tempelaere)" <_N_OSPAMtiti____@hotmail.comMAPSO_N_> wrote in
message news:wNORb.9527$G27.329782@phobos.telenet-ops.be...
[quoted text, click to view]

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