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

[Ken Brady]

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

[Andreas Huber]

Brandon J. Van Every wrote:

Andreas Huber wrote:

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".
Keep It Simple Stupid.

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

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!]

> > there are times when it's useful.

Name one :-).

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!

[Brandon J. Van Every]

Andreas Huber wrote:

Brandon J. Van Every wrote:

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

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.

If you don't understand how that affects
industrial robustness, you are a C++ tweak-head.

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

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.

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.

[Dag Henriksson]

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

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.

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

[Jon Skeet [C# MVP]]

Dag Henriksson <da************@hotmail.com> wrote:

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.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Andreas Huber]

<.> wrote in message news:<uI*************@TK2MSFTNGP11.phx.gbl>...

You call having to DUPLICATE method signitures (prototypes) as good coding?
Its to make up for the bad design in the compilers.
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.

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

[Dag Henriksson]

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

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

--
Dag Henriksson

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.
"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

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

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.

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

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.
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...

<.> wrote in message news:<uI*************@TK2MSFTNGP11.phx.gbl>...

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

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.

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

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.
"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

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.

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

--
Dag Henriksson

[Dag Henriksson]

<di********@discussion.microsoft.com> skrev i meddelandet
news:uN**************@TK2MSFTNGP11.phx.gbl...

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.

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

Doesnt make any sense to have it that way.
"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

<di********@discussion.microsoft.com> skrev i meddelandet
news:uN**************@TK2MSFTNGP11.phx.gbl...

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.

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

[TT \(Tom Tempelaere\)]

<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

Tom.
"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

<di********@discussion.microsoft.com> skrev i meddelandet
news:uN**************@TK2MSFTNGP11.phx.gbl...

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.

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

[Martin Maat [EBL]]

> > > there are times when it's useful.

Name one :-).

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/

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.

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**************@hotmail.comMAPSO_N_> wrote in
message news:wN*******************@phobos.telenet-ops.be...

<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Doesnt make any sense to have it that way.
That is merely an opinion. If it would not make any sense as you state,

C++ language would have changed the concept.

Tom.

"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

<di********@discussion.microsoft.com> skrev i meddelandet
news:uN**************@TK2MSFTNGP11.phx.gbl...
> 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.

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

Any developer who intentionaly obscufates code in any way is out on theyre
ear. We consider them bad designers.
"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

> there are times when it's useful. Name one :-).

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/

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.

I would take it further and say they are a risk to the organization and also
intentional damage and would highlight that to in any references to future
jobs.
<di********@discussion.microsoft.com> wrote in message
news:OQ**************@TK2MSFTNGP09.phx.gbl...

Any developer who intentionaly obscufates code in any way is out on theyre
ear. We consider them bad designers.
"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

> > there are times when it's useful.

> Name one :-).

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/

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.

[Martin Maat [EBL]]

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

Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface
and implementation was just practical, like more of C++'s design decisions
were practical when they were made. It was also a way to publish interfaces
without giving away the code. Because they didn't have type libraries back
then.

It is no use bashing C++ for all the things it doesn't have in 2004
(although I must admit it is great fun to get a rise out of those C++
preachers).

2004? When was C++ spec last updated ?

Function prototypes have NOTHING to do with collapse to definitions in the
VSnet IDE you cluless t.ard. Its there to be a forward reference to the
implementation.. Because the compiler needs to check so we are forced to
make up for that defecency. This could be easily fixed but its not.


"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

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.
Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface
and implementation was just practical, like more of C++'s design decisions
were practical when they were made. It was also a way to publish

interfaces without giving away the code. Because they didn't have type libraries back
then.

It is no use bashing C++ for all the things it doesn't have in 2004
(although I must admit it is great fun to get a rise out of those C++
preachers).

So, according to your bs its there to give away interfaces without code?
Pure BS. IT also gives away INTERNAL information, are you in the habbit of
giving out private internal definitions? Glad you dont work here.
"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

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.
Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface
and implementation was just practical, like more of C++'s design decisions
were practical when they were made. It was also a way to publish

interfaces without giving away the code. Because they didn't have type libraries back
then.

It is no use bashing C++ for all the things it doesn't have in 2004
(although I must admit it is great fun to get a rise out of those C++
preachers).

[Martin Maat [EBL]]

> And what language do you think will be used most in the CLI world and
where

the jobs are :D C#

I wouldn't bet on it. There's a ton of C++ code that will be compiled with
/CLR at some point just to move it to a new platform. That is not likely to
be rewritten in C#.

Just because Microsoft is doing a good job plugging C# doesn't mean that all
of a sudden C++ is dead.

Furthermore, I suspect VB to be bigger (in terms of number of active
developers, code being written) than C# for years to come and I doubt that
C# will ever catch up.

Thats why we have C++/CLI managed extensions. I would imagine most new
projects would be C#, like the redesign of one I am on right now. C++/CLI is
pig fugly.

Im not saying its dead, Im saying thats where alot of work will be heading,
its going that way now and will continue to go. Alot of VB rewrites would
be C#. I am on a rewrite now of old VB6, the guy wanted C++ for its p.enis
extension coolness , i laughed and said no C# is what you are doing because
its perfect for the short dev time for this redesign and more than up to the
job. I would estimate I saved them months of work using it. We also have
non programmer backrounds on the team (specalists in vision) and definatly
because of that C++ = the bad.

He chose C++/CLI for the wrong reasons, coolness and putting hair on his
chest. Typical of an immature, egotistical arrogant developer.


"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

And what language do you think will be used most in the CLI world and where

the jobs are :D C#

I wouldn't bet on it. There's a ton of C++ code that will be compiled with
/CLR at some point just to move it to a new platform. That is not likely

to be rewritten in C#.

Just because Microsoft is doing a good job plugging C# doesn't mean that all of a sudden C++ is dead.

Furthermore, I suspect VB to be bigger (in terms of number of active
developers, code being written) than C# for years to come and I doubt that
C# will ever catch up.

[Martin Maat [EBL]]

> He chose C++/CLI for the wrong reasons, coolness and putting hair on his

chest. Typical of an immature, egotistical arrogant developer.

Ah, so that's what spoiled your mood, you didn't get your way. Well please
go for a walk next time, get a bit of air instead of disrespecting posters
just because your boss won't have you talk to him that way.

No, I got my way and chose C# for a very good reason, He wanted C++/CLI for
not good reasons ie., coolness factor and was not suited to the project in
hand.

I was just highlighting the kind of reasoning that people chose C++ wrongly
at times.
"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

He chose C++/CLI for the wrong reasons, coolness and putting hair on his
chest. Typical of an immature, egotistical arrogant developer.

Ah, so that's what spoiled your mood, you didn't get your way. Well please
go for a walk next time, get a bit of air instead of disrespecting posters
just because your boss won't have you talk to him that way.

[Carl Daniel [VC++ MVP]]

Jon Skeet [C# MVP] wrote:

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

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

[Bronek Kozicki]

[still crossposting and asking for crosspost]

On Wed, 28 Jan 2004 00:21:47 +0100, Martin Maat [EBL] wrote:

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

Could you please provide example code in C#, with the same (or better ;)
) functionality as Carl's example ? It would be interesting to compare
idiom your are proposing with the one described by Carl.

TIA
B.

[Dag Henriksson]

Den Wed, 28 Jan 2004 08:10:19 +0000 skrev Jon Skeet[ C# MVP]:

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.

Well, if you override a method in the derived class you can of course call
that overridden function from within the dervived class. An access
specifier in a base class does not prevent that. THAT would be
counter-intuitive.
But still, you cannot access the method in the base class if it's declared
private, and that's valuable in many design idiom.

--
Dag Henriksson

[Jon Skeet [C# MVP]]

Dag Henriksson <da***@quidsoft.se> wrote:

But still, you cannot access the method in the base class if it's declared
private, and that's valuable in many design idiom.

I can see that there are possibly a few times it would have value - but
I prefer the simplicity (and future-proofing in terms of naming) of the
C# version, myself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Andreas Huber]

di********@discussion.microsoft.com wrote:

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.

Ahhhh there you were heading, you call the separatation of header and
implementation files bad design? Before posting more such ingenious insigts
I strongly suggest you read what the designer of C++ has to say to people
like you:

http://www.research.att.com/~bs/blast.html

Regards,

Andreas

[Andreas Huber]

Brandon J. Van Every wrote:

Andreas Huber wrote:

Brandon J. Van Every wrote:

Keep It Simple Stupid.

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

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.

While I don't know what you mean by "kitchen sink language" (English is not
my mother-tongue) I think I have a faint idea. Here's what Bjarne Stroustrup
has to say about such blanket statements:

http://www.research.att.com/~bs/blast.html

If you don't understand how that affects
industrial robustness, you are a C++ tweak-head.

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

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.

You could say something similar about just about any spoken language
(English, German, ...). However, when you read a poorly written article
(using lots of little-known language constructs in the wrong places,
obfuscating meaning by making overly long sentences, etc. etc.) do you blame
the language for it? No you don't (at least none of the people I know do),
you blame the writer. Why people blame C++ when they see poorly written code
is beyond me.
It is only natural that you can obfuscate code more in a language that
offers more features helping abstraction. The Java designers once had the
idea of creating a really simple language that everybody can learn in a few
days. I guess I don't have to lecture you that this is no longer the case
with Java 1.5. C# had many more features than Java 1.0 right from the
beginning and they'll add more with the next version of VS. What does that
tell you?

TMK, no C++ expert has ever mentioned private virtuals in this
respect.

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

There *are* C# experts and from the sheer volume of traffic on
microsoft.public.dotnet.languages.csharp I'd say C#ers definitely need them.

Regards,

Andreas

[Andreas Huber]

[snip]

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.
I don't see why it is C++ fault when ignorant programmers abuse features
they don't understand. Moreover, C# is getting more complex with the next
version and even today people criticize C# for being too complex:

http://groups.google.com/groups?hl=e...tron.net#link1

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

Language wars are silly.

Regards,

Andreas

[Martin Maat [EBL]]

"Bronek Kozicki" <br**@rubikon.pl> wrote in message
news:rq*****************************@40tude.net...

[still crossposting and asking for crosspost]
Nah, let them read it here.
On Wed, 28 Jan 2004 00:21:47 +0100, Martin Maat [EBL] wrote:

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

Could you please provide example code in C#, with the same (or better ;) )
functionality as Carl's example ? It would be interesting to compare
idiom your are proposing with the one described by Carl.

Okay, we used a number of terms in the past posts ranging from polymophism
to events and delegates. What the purpose of Carl's example boils down to is
to that of a callback. In C# "delegates" are used to implement both events
and callbacks. One could argue that events basically are callbacks, let's
not get into that right now.

I say if you really want a callback, then don't use polymorphism because
using ploymorphism is a semantical statement (I like big words, please
forgive me). It implies that there is some basic entity that may have
different incarnations. In Carl's example this is not the case, there it is
plain vanilla straight ahead processing with the possibility for the client
to hook into the control flow (I am really enjoying this).

I read about delegates a couple of weeks ago in "Inside C# 2nd edition" and
grasped about half of it. The identifier names weren't all that well chosen
which made it hard to read and I thought I'd have a closer look the first
time I would need it. Which is now, you gave me the little push I needed.

I tried to stay close to the original idea of a series of tasks that should
be inaccessable from the client's side apart from one particular sub-task
that the client may replace. A string is build and the client gets the
oppurtunity to insert its piece in it. If it declines a defaul piece is used
instead.
=============== START OF CODE ===================

using System;
using System.Text;

class PlugHost
{
private string data;

public delegate void ExternalProcessorDelegate(ref string data);
public void DoProcessingAndDelegatePartOfTheWork(ExternalProce ssorDelegate
custom)
{
data = "_StandardPartA_";

// (only) if the client provided its own logic,
// use that to obtain the middle part.
if (custom == null)
{
data += "_StandardPartB_";
}
else
{
string strCustom = null;
custom(ref strCustom);
data += strCustom;
}

// add another standard part
data += "_StandardPartC_";
}
public string GetResult() { return data; }
}

class App
{
static private void MyCustomProcessor(ref string s)
{
// add my two cents to the effort
s = "CustomPart";
}

static void Main()
{
PlugHost plugHost = new PlugHost();
// wrap reference to MyCustomProcessor in delegate
PlugHost.ExternalProcessorDelegate myProcessorDelegate = new
PlugHost.ExternalProcessorDelegate(MyCustomProcess or);

// call DoProcessingAndDelegatePartOfTheWork, passing the delegate
plugHost.DoProcessingAndDelegatePartOfTheWork(myPr ocessorDelegate);

Console.WriteLine("Result: {0}", plugHost.GetResult());
}
}

=============== END OF CODE ===================
Martin.

[Martin Maat [EBL]]

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

I don't see why it is C++ fault when ignorant programmers abuse features
they don't understand. Moreover, C# is getting more complex with the next
version and even today people criticize C# for being too complex:

No one is blaming anyone or anything. We just feel it is a good idea to
avoid language constructs that are easily misunderstood when designing a
language. We can now look back and make judgements about particular language
features, weighing the costs aganst the benefits. Some features may have
proven to be more of a burden than a bless. Of course it will always be the
programmer's fault but that naked assessment will not make up for the damage
done. It is a good thing that the industry is learning from its mistakes.
Making things "tricky" has proven to be too expensive just to say "fat luck,
you should have hired smarter programmers".

We have safety belts, we have fire alarms and we are going to program
managed code using new languages.

It is only natural to frown on a next generation of anything and since you
are dragging in hot shots to support your case, here's a quote from a
reasonable informed guy in the industry: "I don't need no stinkin' garbage
collector, I obviously know what I'm doing". And he too was turned around
pretty soon too :-).

Martin.
The quote is Jeffrey Richter's, sharing his early emotions on .NET with the
audience at the Developer Days 2002 in The Netherlands.

[Andreas Huber]

Martin Maat [EBL] wrote:

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.

I don't see why it is C++ fault when ignorant programmers abuse
features they don't understand. Moreover, C# is getting more complex
with the next version and even today people criticize C# for being
too complex:

No one is blaming anyone or anything. We just feel it is a good idea
to avoid language constructs that are easily misunderstood when
designing a language. We can now look back and make judgements about
particular language features, weighing the costs aganst the benefits.
Some features may have proven to be more of a burden than a bless. Of
course it will always be the programmer's fault but that naked
assessment will not make up for the damage done. It is a good thing
that the industry is learning from its mistakes. Making things
"tricky" has proven to be too expensive just to say "fat luck, you
should have hired smarter programmers".

We have safety belts, we have fire alarms and we are going to program
managed code using new languages.

It is only natural to frown on a next generation of anything and
since you are dragging in hot shots to support your case, here's a
quote from a reasonable informed guy in the industry: "I don't need
no stinkin' garbage collector, I obviously know what I'm doing". And
he too was turned around pretty soon too :-).

I guess I have to clarify that I'm quite fond of C# and I use it for most of
my current programming work (I also still use C++). I only posted in this
thread because someone else made IMO unfounded statements about C++. The
archives'll tell you that I do the same when someone makes IMO unfounded
statements about C#.

Regards,

Andreas

[Hendrik Schober]

Brian Ross <br**********@rogers.com> wrote:

[...]
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.
The difference is, that when you make
'f()' private in the base class, authors
of derived classes won't have to wonder
whether to call 'f()' or not.
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.
Right. Usually that's a good thing.
Brian

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

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.
Okay, that makes sense. Technically that is.

there are times when it's useful.

Name one :-).

The Template Method pattern:

class Interface {
public:
void algorithm()
{
some_stuff();
customizable_stuff();
some_more_stuff();
more_customizable_stuff();
}
private:
void some_stuff() {}
void some_more_stuff() {}
virtual void customizable_stuff() = 0;
virtual void more_customizable_stuff() {}
};

The 'algorithm()' member function implements
some algorithm. Derived classes can plug into
this and customize some of it.
There is no need for derived classes to call
'customizable_stuff()' etc. directly, and thus
they shouldn't be allowed. However, they can
(in the pure virtual case: must) replace them.
Just by looking at the class declaration, this
is clear right away to anyone knowing the
pattern.
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!.
"Here is a method, that you can override.
No, you shouldn't call it. Oh right, it
says so on the lable already."
Martin.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

[...] However, Jim

Hyslop and Herb Sutter wrote a nice article that provided a reasonable
example: http://www.cuj.com/documents/s=8000/cujcexp1812hyslop/
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.

Only if they don't know the patterns used.
With the very same argument, you can reject
the usage of increment/decrement operators,
since they just hide what's really done
from people who don't know them.
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.
In the years I am using C/C++, I have come
across many, many things which I considered
very, very couter-intuitive. Yet they are
done regularly and understood by most (for
some definition of "most") programmers (for
some definition of "programmers"). For many
of those, it was just that I hadn't learned
enough yet. (For some I'd still argue.)
It was the very same with private virtuals.
If you use google, you might find that at
one (not so long ago) time I was stunned to
learn that this even is possible. Now I use
it regularly. At first, my co-workers were
stunned when they saw it. Any guess what:
Meanwhile, they start to use it, too.
[...]
Martin.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

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

"Industrial robustness" in the real world means simplifying things so
that the vast majority of average programmers understand what's going
on.

[...]

I really fail to see how private virtuals hurt "industrial robustness".

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,
[...]

With the same reasoning you could reject
any tool more complicated than a hammer
and a bag of nails, since you can misuse
them in so many hurtful ways. Yet, in the
hand of a skilled craftsman, they can be
very powerful tools that allow him to do
things that are less elegant or very hard
to do without them.
In the private virtual discussion, robustness may not be an issue. I would
call it "not elegant".
I find Template Method a _very_ elegant
pattern. Once you explain it to someone,
they know exactly what it is about, how
to use it, and how to recognize it. And
using private virtuals, it does exactly
what the class declaration indicates it
is doing.
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.
Yeah. Seems like private virtual are new
to many here.
And oh (I almost forgot): "my language is better than yours".
According to which definition of "good"? :)
Martin.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

[...]
No one is blaming anyone or anything. We just feel it is a good idea to
avoid language constructs that are easily misunderstood when designing a
language. [...]
Define "easily". Oh, and for whom?
I have been teaching programming and
IMO every language is too hard to
grasp for someone, and easily used
by others.
[...]
Martin.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

[...]
Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface
and implementation was just practical [...]

If I hadn't been taught it before, the
first time I came across an app that
had a couple 100kLOC, with many people
designing and implementing parts of it
simultaniously, I know what separation
of interface and implementation is good
for. IMHO that's why so many languages
have it.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

di********@discussion.microsoft.com <di********@discussion.microsoft.com> wrote:

2004? When was C++ spec last updated ?
2003.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

di********@discussion.microsoft.com <di********@discussion.microsoft.com> wrote:

And what language do you think will be used most in the CLI world and where
the jobs are :D C#
Ugh, that again.
For a sterter, what language do you think the
foundations of the CLI are written in?
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

Uhh what language do you think I code with C# ?
"Hendrik Schober" <Sp******@gmx.de> wrote in message
news:eM**************@TK2MSFTNGP11.phx.gbl...

di********@discussion.microsoft.com <di********@discussion.microsoft.com>

wrote:

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

Ugh, that again.
For a sterter, what language do you think the
foundations of the CLI are written in?

[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Martin Maat [EBL] wrote:

"Bronek Kozicki" <br**@rubikon.pl> wrote in message
news:rq*****************************@40tude.net...

[still crossposting and asking for crosspost]
Nah, let them read it here.

On Wed, 28 Jan 2004 00:21:47 +0100, Martin Maat [EBL] wrote:

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

Could you please provide example code in C#, with the same (or
better ;) ) functionality as Carl's example ? It would be
interesting to compare idiom your are proposing with the one
described by Carl.

Okay, we used a number of terms in the past posts ranging from
polymophism to events and delegates. What the purpose of Carl's
example boils down to is to that of a callback.

This is not true. The flow-control pattern that exists in my example is
similar to that of a callback. The purpose, however, is completely
different. The example you provided is one of a "client" hooking into the
behavior of an object. While a derived class is a "client" of it's base, it
is a very special kind of client. The idiom that I illustrated shows how a
base class (think interface, but in abstract terms, not C# terms) can be
constructed to ensure that ALL classes that implement that interface satisfy
the invariants (guarantees) that the interface designer intended. Delegates
cannot provide this guarantee, since there's no way to REQUIRE that a
derived class (or client) actually provide a delegate to one of it's methods
and hook it into the correct event of the base class.
In C# "delegates" are
used to implement both events and callbacks. One could argue that
events basically are callbacks, let's not get into that right now.

Delegates (and events) in C# are precisely (and solely) a systematic
mechanism for creating and invoking callbacks. Nothing more. That's not to
say they're not useful - they are quite useful. But they're not a mechanism
one would use to implement design by contract.

-cd

[Martin Maat [EBL]]

> > Well, they didn't have these fancy editors back then that enabled the

programmer to collaps the implemantation did they? So seperating interface and implementation was just practical [...]
If I hadn't been taught it before, the first time I came across an app

that had a couple 100kLOC, with many people designing and implementing
parts of it simultaniously, I know what separation of interface and
implementation is good for. IMHO that's why so many languages
have it.

No, don't mean a thing. What you are refering to is having separate
(implementation) code files for different parts of a system. That is a good
thing. Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically
does not bring any gain as far as maintainability is concerned. You will
always lock both when working on either. Working on just the interface
without touching the implementation is pointless and if you are changing the
implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to
mess with the implementation as well.

Mind that the idea of .c and .h files stems from the pre-OO days. People
mainly extended that to .cpp and .h because they were used to working that
way. For class definitions there is no point in doing so as far as
maintainability is concerned..

With C# it is not only because there is no longer a practical need for
separation that everything is in one file now, it is a design decision based
on the notion that a class definition is a self-contained unit. Think of the
problems that would arise for the namespace system if it were different.

Martin.

[Martin Maat [EBL]]

> > No one is blaming anyone or anything. We just feel it is a good idea to

avoid language constructs that are easily misunderstood when designing a
language. [...]

Define "easily". Oh, and for whom? I have been teaching programming and
IMO every language is too hard to grasp for someone, and easily used
by others.

As a teacher of programming languages you will acknowledge that in C it is
relatively easy to write code that does something different than what you
intended yet compiles without any problem. In Pascal it is a lot harder to
do that, even in Basic it is a lot harder to do that. Just a few examples:

if (a = 3) { /* do whatever */ } // I mean "if a equals 3, do whatever"
but instead a is assigned the value 3 which evaluates to true.
MyFunction; // I want to execute the function but by forgetting the
parenthesis a function pointer is evaluated and dropped into a void instead.
Case fall-though is another nice one.

It is for good reason that in championships for writting the most obfuscated
one-liner the C language rules :-).

Martin.

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface
and implementation was just practical [...]
If I hadn't been taught it before, the first time I came across an app that
had a couple 100kLOC, with many people designing and implementing
parts of it simultaniously, I know what separation of interface and
implementation is good for. IMHO that's why so many languages
have it.

No, don't mean a thing. What you are refering to is having separate
(implementation) code files for different parts of a system.

No. What I am talking about it having the
interface separated from its implementation.
That is a good
thing. Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically
does not bring any gain as far as maintainability is concerned.
It does. It makes clients independand of
the implementation. They only depend on
the interface.
You will
always lock both when working on either.
I rarely ever change a header.
(I'd be dead within a week if I did change
interfaces half as often as I change their
implementations. People would be queueíng
at the table tennis room while their
machines are locked with the compiler
running and had a _lot_ of time to consider
what bad things to do to me. :o> )
Working on just the interface
without touching the implementation is pointless and if you are changing the
implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to
mess with the implementation as well.
Althoguh I think it is possible, it is
uncommon to lock files using CVS. I have
never done it and haven't heard from anyone
doing it here.
Mind that the idea of .c and .h files stems from the pre-OO days. People
mainly extended that to .cpp and .h because they were used to working that
way. For class definitions there is no point in doing so as far as
maintainability is concerned..
You're kidding, aren't you?
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface? 'X' was designed a long time
ago, its interface had a lot of time to
mature -- it is stable. I I change its
interface just so, everyone on the project
will be prevented from working for an hour
or two, just so. I wouldn't dream of doing
this without discussing the changes first.
All I need to do is fix 'X::f()'.
With C# it is not only because there is no longer a practical need for
separation that everything is in one file now, it is a design decision based
on the notion that a class definition is a self-contained unit. Think of the
problems that would arise for the namespace system if it were different.
I don't know C# and I don't know its
namespace system. What I know is this: If
I cause everybody here to recompile just
because I fix some implementation, I'd
be in serious trouble.
Martin.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Martin Maat [EBL] <du***@somewhere.nl> wrote:

No one is blaming anyone or anything. We just feel it is a good idea to
avoid language constructs that are easily misunderstood when designing a
language. [...]
Define "easily". Oh, and for whom? I have been teaching programming and
IMO every language is too hard to grasp for someone, and easily used
by others.

As a teacher of programming languages you will acknowledge that in C it is
relatively easy to write code that does something different than what you
intended yet compiles without any problem. In Pascal it is a lot harder to
do that, even in Basic it is a lot harder to do that. [...]

Right. But first, we are talking C++ here
(stronger type checking, 'const', less use
for the preprocessor etc.). Second, while
it might still be relatively easy to write
some obfuscated code in C++, we were not
talking about "some code" here, but about
private virtual functions and whether they
are a language construct that is easily
misunderstood.
(Incidently, I taught the use of such just
last week. Nobody found them specifically
strange, nobody asked any question about
them, and in their homework they'll just
use it.)
[...]
It is for good reason that in championships for writting the most obfuscated
one-liner the C language rules :-).
I think with the operator overloading,
implicit conversions and all that stuff,
C++ would be a lot easier to write
obfuscated code if you wanted to.
Martin.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[TT \(Tom Tempelaere\)]

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

No one is blaming anyone or anything. We just feel it is a good idea to avoid language constructs that are easily misunderstood when designing a language. [...]
Define "easily". Oh, and for whom? I have been teaching programming and IMO every language is too hard to grasp for someone, and easily used
by others.

As a teacher of programming languages you will acknowledge that in C it is
relatively easy to write code that does something different than what you
intended yet compiles without any problem. In Pascal it is a lot harder to
do that, even in Basic it is a lot harder to do that. Just a few examples:

if (a = 3) { /* do whatever */ } // I mean "if a equals 3, do whatever"
but instead a is assigned the value 3 which evaluates to true.
MyFunction; // I want to execute the function but by forgetting the
parenthesis a function pointer is evaluated and dropped into a void

instead. Case fall-though is another nice one.
A quality compiler will probably produce a warning that the expression
always evaluates to true (if a is a numeric type). Hopefully ending the
warning with 'Is this what you intended?' ;-). But as the quality of the
compilers increase, so should the quality of warnings. And since warnings
can be errors that is a good thing.

But:
int g(int x);
// ...
int x=3, a;
if( a = g(x) ) { ... }

Would quality compilers warn about that? Suppose you intended it?

Tom.
It is for good reason that in championships for writting the most obfuscated one-liner the C language rules :-).

Martin.

[TT \(Tom Tempelaere\)]

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

No one is blaming anyone or anything. We just feel it is a good idea to avoid language constructs that are easily misunderstood when designing a language. [...]
Define "easily". Oh, and for whom? I have been teaching programming and IMO every language is too hard to grasp for someone, and easily used
by others.

As a teacher of programming languages you will acknowledge that in C it is
relatively easy to write code that does something different than what you
intended yet compiles without any problem. In Pascal it is a lot harder to
do that, even in Basic it is a lot harder to do that. Just a few examples:

if (a = 3) { /* do whatever */ } // I mean "if a equals 3, do whatever"
but instead a is assigned the value 3 which evaluates to true.
MyFunction; // I want to execute the function but by forgetting the
parenthesis a function pointer is evaluated and dropped into a void

instead. Case fall-though is another nice one.
A quality compiler will probably produce a warning that the expression
always evaluates to true (if a is a numeric type). Hopefully ending the
warning with 'Is this what you intended?' ;-). But as the quality of the
compilers increase, so should the quality of warnings. And since warnings
can be errors that is a good thing.

But:
int g(int x);
// ...
int x=3, a;
if( a = g(x) ) { ... }

Would quality compilers warn about that? Suppose you intended it?

Tom.
It is for good reason that in championships for writting the most obfuscated one-liner the C language rules :-).

Martin.