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

[Guest]

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.

 

[Guest]

Doesnt make any sense to have it that way.

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

 

[TT \(Tom Tempelaere\)]

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.

 

[Martin Maat [EBL]]

there are times when it's useful.

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.

 

[Guest]

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

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.

 

[Guest]

Any developer who intentionaly obscufates code in any way is out on theyre
ear. We consider them bad designers.

 

[Guest]

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.

 

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

 

[Martin Maat [EBL]]

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

the jobs are 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.

 

[Guest]

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.

 

[Guest]

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.

 

[Guest]

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

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

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

 

[Guest]

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.

 

[Bronek Kozicki]

[still crossposting and asking for crosspost]

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.

 

[Jon Skeet [C# MVP]]

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.

 

[Andreas Huber]

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]

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

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?

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