473,842 Members | 1,933 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

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....
Nov 15 '05
175 8932
Martin Maat [EBL] <du***@somewher e.nl> wrote:
[...]
So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
If they care for the update they may want to recompile. If they don't, they
will not recompile. I'm not sure I understand what you are worried about.


I am worried about having to recompile
files that depend on the interface of a
module when only its implementation
changed.
Why should I lock a header if I won't change it???


To make sure that once you check in your updated implementation and unlock
your interface, the result will be consistent. You will be sure the
interface that matches the implementation has not been changed.


I am sure, since I merge any changes
into my code before I it check in.
CVS, the version control system.
(www.cvshome.org)


Are you dislectic by any change?


???
Ah, CVS stands for "Concurrent Versions
System". What was so bad about Visual SourceSafe?
We needed to run analyze every night and
still lost changes since it didn't repair
everything the clients messed up. Branching
is a PITA in VSS. Remote access, too.
AFAIK, MS doesn't use VSS for their own
software. And I can understand this.
As I said, I never lock anything. If anyone changed anything I was working
on, I merge this into my local version (and test it) before I checkin the file(s).


Oh, that's nice. Why not keep everything on your local machine and ship that
version once it is time to release?


Because that would hurt.
We have dedicated build machines for
this. If I need a release, a script
will do a clean check out on a label,
build this version, run some tests,
and build the installer.
The result will eventually be shipped.
You are proving my point. If you do lock the stuff that belongs together no
one can change anything while you're working on it.
Since you haven't even heard of CVS,
how do you think you can judge the way
it is used to work? The way I described
(Have you ever looked at SourceForge?
Can you imagine this be to done using
VSS? With the developers spread all
over the world?)
> 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? Just lock, not change.
Why would I need to lock the interface?


I give up, you win.


No, it was a serious question.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.


You seem awefully afraid of recompilation. Could you be working on this one
big monolithic application in which everything depends on everything for
which any change will cause a chain reaction in the C++ compiler, rendering
your machine useless for 20 minutes? Could it be someone influencial in your
company declared "Build All" the only way to compile and had the compile
option removed from all of your Visual Studio installations? I don't see the
problem, recompilation of one class should not be issue.


Currently I work on a 700kLOC+ app. Of
this, 500kLOC+ were written in-house. And
that's not old, longish C code. All C++,
the oldest code ~5 years old, much of it
done one year ago; a lot of care went into
preventing redundancy and dependencies,
and into clean modularization. (We test
modules individually, after all). Yet, a
full rebuild of all the projects involved
takes ~60min. If I ever wanted to rebuild
all the test projects, too, it would take
another few hours.
This is one of those projects, where, if
you are going to do some major changes to
some part of it, you first write a test
program for this, then do your changes,
and test them in the main app only after
you are sure the (re-)design done and
you found most of the mistakes you made.
It simply is faster this way.

Recompilation of a class' implementation
is no issue. OTOH, changing the interface
of a class is something not done without
consideration in such a project, as it
forces all dependend modules to be re-
compiled.
I definitely wouldn't want to do do such
an app using a language where a change in
the implementation of one class forces a
recompilation of all modules depending
on its interface.
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
Nov 15 '05 #111
Martin Maat [EBL] <du***@somewher e.nl> wrote:
[...]
So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
If they care for the update they may want to recompile. If they don't, they
will not recompile. I'm not sure I understand what you are worried about.


I am worried about having to recompile
files that depend on the interface of a
module when only its implementation
changed.
Why should I lock a header if I won't change it???


To make sure that once you check in your updated implementation and unlock
your interface, the result will be consistent. You will be sure the
interface that matches the implementation has not been changed.


I am sure, since I merge any changes
into my code before I it check in.
CVS, the version control system.
(www.cvshome.org)


Are you dislectic by any change?


???
Ah, CVS stands for "Concurrent Versions
System". What was so bad about Visual SourceSafe?
We needed to run analyze every night and
still lost changes since it didn't repair
everything the clients messed up. Branching
is a PITA in VSS. Remote access, too.
AFAIK, MS doesn't use VSS for their own
software. And I can understand this.
As I said, I never lock anything. If anyone changed anything I was working
on, I merge this into my local version (and test it) before I checkin the file(s).


Oh, that's nice. Why not keep everything on your local machine and ship that
version once it is time to release?


Because that would hurt.
We have dedicated build machines for
this. If I need a release, a script
will do a clean check out on a label,
build this version, run some tests,
and build the installer.
The result will eventually be shipped.
You are proving my point. If you do lock the stuff that belongs together no
one can change anything while you're working on it.
Since you haven't even heard of CVS,
how do you think you can judge the way
it is used to work? The way I described
(Have you ever looked at SourceForge?
Can you imagine this be to done using
VSS? With the developers spread all
over the world?)
> 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? Just lock, not change.
Why would I need to lock the interface?


I give up, you win.


No, it was a serious question.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.


You seem awefully afraid of recompilation. Could you be working on this one
big monolithic application in which everything depends on everything for
which any change will cause a chain reaction in the C++ compiler, rendering
your machine useless for 20 minutes? Could it be someone influencial in your
company declared "Build All" the only way to compile and had the compile
option removed from all of your Visual Studio installations? I don't see the
problem, recompilation of one class should not be issue.


Currently I work on a 700kLOC+ app. Of
this, 500kLOC+ were written in-house. And
that's not old, longish C code. All C++,
the oldest code ~5 years old, much of it
done one year ago; a lot of care went into
preventing redundancy and dependencies,
and into clean modularization. (We test
modules individually, after all). Yet, a
full rebuild of all the projects involved
takes ~60min. If I ever wanted to rebuild
all the test projects, too, it would take
another few hours.
This is one of those projects, where, if
you are going to do some major changes to
some part of it, you first write a test
program for this, then do your changes,
and test them in the main app only after
you are sure the (re-)design done and
you found most of the mistakes you made.
It simply is faster this way.

Recompilation of a class' implementation
is no issue. OTOH, changing the interface
of a class is something not done without
consideration in such a project, as it
forces all dependend modules to be re-
compiled.
I definitely wouldn't want to do do such
an app using a language where a change in
the implementation of one class forces a
recompilation of all modules depending
on its interface.
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
Nov 15 '05 #112
> First, virtual methods do not come free, they perform worse than non-virtual
methods.
This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.
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...
It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.
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.
If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.
It would only invite developers to screw things up and they would not
understand what is expected of them.
Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.

** Don't protect me from myself **

Martin Maat wrote:
Ken,
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?


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

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.


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #113
> First, virtual methods do not come free, they perform worse than non-virtual
methods.
This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.
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...
It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.
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.
If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.
It would only invite developers to screw things up and they would not
understand what is expected of them.
Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.

** Don't protect me from myself **

Martin Maat wrote:
Ken,
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?


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

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.


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #114
Bret Pehrson <br**@infowest. com> wrote:
First, virtual methods do not come free, they perform worse than non-virtual
methods.
This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.


Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
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...


It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.


The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
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.


If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.


see above
It would only invite developers to screw things up and they would not
understand what is expected of them.


Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.


If a desing expresses its intention, that's
a lot bettern than having to read a lot of
documentation in order to understand the
intention.
** Don't protect me from myself **
Don't expect us to carefully read douments
that contradict your code.
[...]


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
Nov 15 '05 #115
Bret Pehrson <br**@infowest. com> wrote:
First, virtual methods do not come free, they perform worse than non-virtual
methods.
This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.


Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
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...


It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.


The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
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.


If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.


see above
It would only invite developers to screw things up and they would not
understand what is expected of them.


Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.


If a desing expresses its intention, that's
a lot bettern than having to read a lot of
documentation in order to understand the
intention.
** Don't protect me from myself **
Don't expect us to carefully read douments
that contradict your code.
[...]


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
Nov 15 '05 #116
> Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
I'm not a compiler writer, nor a hardware design engineer. The fact remains,
the original statement is about an implementation (whether or not it applies to
all current implementations or not is irrelevant).

With hardware advanced as it is, especially w/ predictive processing/branching,
you can't assume anything about performance.
The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
Not true.

class A
{
public:
virtual void a()
{
// do something
}
};

class B : public A
{
public:
virtual void a()
{
A::a();
trace("processi ng a");
}
}

This doesn't change behavior, but is a very valid and real-world case of
virtual overrides.
Don't expect us to carefully read douments
that contradict your code.
???

I do expect you to carefully read documents that define the behavior, usage,
and intent of my interfaces.
Hendrik Schober wrote:
Bret Pehrson <br**@infowest. com> wrote:
First, virtual methods do not come free, they perform worse than non-virtual
methods.


This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.


Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
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...


It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.


The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
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.


If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.


see above
It would only invite developers to screw things up and they would not
understand what is expected of them.


Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.


If a desing expresses its intention, that's
a lot bettern than having to read a lot of
documentation in order to understand the
intention.
** Don't protect me from myself **


Don't expect us to carefully read douments
that contradict your code.
[...]


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


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #117
> Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
I'm not a compiler writer, nor a hardware design engineer. The fact remains,
the original statement is about an implementation (whether or not it applies to
all current implementations or not is irrelevant).

With hardware advanced as it is, especially w/ predictive processing/branching,
you can't assume anything about performance.
The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
Not true.

class A
{
public:
virtual void a()
{
// do something
}
};

class B : public A
{
public:
virtual void a()
{
A::a();
trace("processi ng a");
}
}

This doesn't change behavior, but is a very valid and real-world case of
virtual overrides.
Don't expect us to carefully read douments
that contradict your code.
???

I do expect you to carefully read documents that define the behavior, usage,
and intent of my interfaces.
Hendrik Schober wrote:
Bret Pehrson <br**@infowest. com> wrote:
First, virtual methods do not come free, they perform worse than non-virtual
methods.


This is a generalized statement regarding an *IMPLEMENTATION * of the language,
not the language itself.


Can you tell us about any implementation
where this isn't true? Or even only
describe how such an implementation would
work?
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...


It doesn't/shouldn't imply anything. If the user relies in implications, they
are going to have problems with their code regardless of the construct at hand.

Remember, that virtual doesn't mean that the overriding method has to do
*anything*, it may be simply tracking, monitoring, or triggering a response.
These are all *VALID* uses of virtual, and have absolutely NOTHING to do w/
changing behavior.


The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
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.


If they MUST NOT be overridden for **ANY** reason, then they shouldn't be
virtual. If they shouldn't be overridden in such a way as to change behavior,
they should be virtual and that fact should be in the documentation.


see above
It would only invite developers to screw things up and they would not
understand what is expected of them.


Then document it better. Like I said, if they have to rely on implications or
assumptions, they are going to screw it up, regardless of virtuality.


If a desing expresses its intention, that's
a lot bettern than having to read a lot of
documentation in order to understand the
intention.
** Don't protect me from myself **


Don't expect us to carefully read douments
that contradict your code.
[...]


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


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #118
di********@disc ussion.microsof t.com wrote:
And what language do you think will be used most in the CLI world and
where the jobs are :D C#


You don't get it, do you? There are classes of applications for which
C#/Java is either too expensive in terms of ROM/RAM footprint (systems where
the hardware costs are considerably higher than the one for software) or
simply the wrong choice (hard realtime systems, device drivers). For these
applications C++ will be *the* language for *at least* another decade. C#
and Java are here to stay and that's a good thing but these languages will
not be able to to take over everything from C++.

*Every* language has it's pros and cons and language wars are thus just
plain pointless, especially when you argue with beliefs instead of technical
facts...

Regards,

Andreas

Nov 15 '05 #119
No but hey, tell that to the employers out there advertising for C# skills
:D

What do I know eh.

Sure with hardreal time you dont want dynamic memory allocation, obviously
captain obvious. This are specalized cases, for the more run of the mill
applications C# is perfect with short project cycles (which is more and more
common) and managibility of bugs and the current drive for more security via
a managed environment.

Ofcourse C++ is still used but watch C# take the mainstream applications and
C++ for specific interop and time / memory critical applications. C# will
be the dominant language in the mangaged world and C+/CLI for specific needs
however this will be kept and should be kept to a minimum as the
managability of that code is too tangled and messy.

Alot of redesign of applications I have worked on are all going C#. They are
moving away from Propriety languages like VB and java towards more
standardized ones for level playing fields and less lockin from the likes of
MS and Sun.


"Andreas Huber" <ah****@gmx.net > wrote in message
news:40******** @news.bluewin.c h...
di********@disc ussion.microsof t.com wrote:
And what language do you think will be used most in the CLI world and
where the jobs are :D C#
You don't get it, do you? There are classes of applications for which
C#/Java is either too expensive in terms of ROM/RAM footprint (systems

where the hardware costs are considerably higher than the one for software) or
simply the wrong choice (hard realtime systems, device drivers). For these
applications C++ will be *the* language for *at least* another decade. C#
and Java are here to stay and that's a good thing but these languages will
not be able to to take over everything from C++.

*Every* language has it's pros and cons and language wars are thus just
plain pointless, especially when you argue with beliefs instead of technical facts...

Regards,

Andreas

Nov 15 '05 #120

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

164
8069
by: Ken Brady | last post by:
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....
0
9870
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, weíll explore What is ONU, What Is Router, ONU & Routerís main usage, and What is the difference between ONU and Router. Letís take a closer look ! Part I. Meaning of...
0
9715
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10610
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10671
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7035
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5696
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4499
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4088
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3142
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.