C# vs. C++

[Hendrik Schober]

Re: C# vs. C++

Alvin Bruney [ASP.NET MVP] wrote:

[...]

>The single most glaringly obvious example of what I mean is that you
>can't do template metaprogramming in C#, but there are others.

>
And what is that good for? [...]

It shifts tasks from the run-time to the compile-time. IMO
the biggest advantage of this is that you catch more errors
at compile-time. OTOH, this allows C++ to rival FORTRAN's
speed for some applications, which for some people is far
more important.
I wouldn't call these obscure features.

Schobi

[Daniel James]

Re: C# vs. C++

In article news:<485eee18$ 0$90272$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

C# also has abstract classes and even though abstract classes can
be used instead of interfaces, then interfaces especially when
combined with the only inherit from one class but implement
multiple interfaces rules really guide users towards good
OOP style.

I think your notion of "good OOP style" is misplaced. You are saying
what Java programmers have been saying that for some time -- because
Java doesn't give them any choice.

You are, of course, free to follow that convention in C++ -- but if you
do so you will be limiting your design choices. There is nothing
inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<101D0CAB-378E-4B1C-9F18-B2D243CEBF11@mi crosoft.com>,
Alvin Bruney [ASP.NET MVP] wrote:

Don't confuse flexibility with lack of safety -- you can have the
one without the other.

>
How is this confused? My point was C# is not less flexible because
it allows pointer tricks, ...

... and your point is misplaced because it is largely not the ability to
perform "pointer tricks" that makes C++ more flexible or more powerful.

Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.) -- which C# is not -- but on most modern architectures (with
hardware memory management and address remapping) C++'s addresses don't
correspond to meaningful physical memory addresses anyway.

No, pointer manipulation is not what we're discussing, here.

The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.

>
And what is that good for?

If you have no conception of the answer to that question I can't hope to
persuade you that you are missing something very important.

I wouldn't go searching for obscure features to compare against C#.
What I would do is compare common code paths and implementation.
Like it or not, C++ is a dying sport. Holding on to obscurities
will not inject life into it.

There's nothing obscure about TMP. It's what makes the C++ standard
library so hugely powerful, it's what makes some of the amazingly useful
libraries in, for example, Boost possible. Modern C++ code is built on
templates and it makes the language hugely more powerful than a
classical OOP language like C# or Java could ever hope to be. Even if a
C++ programmer never writes a single template in his whole life he has
all the power of those libraries to draw upon.

more strictly, to provide a plugin replacement for Java

That's new. By the same token C++ was what to C?

C++ is based on C, but is not a simple replacement. The syntax of C++ is
almost a proper superset of that of C (i.e. most, but not all C source
will compile correctly if fed through a C++ compiler) with new semantics
and new functionality that represent an evolutionary increase in
flexibility and power.

C# is based on Java. It has a slightly different syntax and a different
set of runtime APIs, but it is semantically very similar -- a little
better, because some of the mistakes of Java were not repeated, but
largely similar. Where is the evolutionary advance here? Nowhere.

It's time to let go of C++. Really, it is. It's done for.

You really have no idea.

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<48603eff$ 0$90276$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

I'd call that a positive result! Certainly better than getting 50
mediocre programmers.

>
Seen from a puristic point of view I will agree. But there
is this aspect of the world called money - we need millions
of programmers to code business apps.

10 first class programmers will do more useful work in less time than
50 mediocre programmers ... and you will get fewer bugs.

In a world with concerns such as money you can't afford the mediocre.

Cheers,
Daniel.

[David Wilkinson]

Re: C# vs. C++

Alvin Bruney [ASP.NET MVP] wrote:

It's time to let go of C++. Really, it is. It's done for.

Says who?

C++/CLI as a first class .NET language does indeed appear doomed. Maybe using
C++ for .NET was a bad concept from the beginning, or maybe it was done in by
the flawed initial version of MC++. But, anyway, it seems dead.

C++/CLI is great for inter-op, but that is a limited market compared to all the
things that C# can do in .NET.

But native C++ lives on, both as a cross platform language, and in many
MFC/Win32 applications that are never going to switch to .NET. The Visual C++
team is strongly committed to improve the native coding experience in the next
version of Visual Studio, after many years of neglect.

It is a pity that MFC is a bloated and not very elegant framework, but it works.
It can still be used to create applications that would be difficult to do in C#.

And if you do not like MFC, there are WTL, wxwidgets, QT ... A lot of C++ code
is non-GUI anyway.

C++ is not dead yet. And C# is not the perfect language either. Too much
influenced by Java, IMHO.

--
David Wilkinson
Visual C++ MVP

[Andre Kaufmann]

Re: C# vs. C++

Daniel James wrote:

In article news:<101D0CAB-378E-4B1C-9F18-B2D243CEBF11@mi crosoft.com>,
Alvin Bruney [ASP.NET MVP] wrote:

>>Don't confuse flexibility with lack of safety -- you can have the
>>one without the other.

>How is this confused? My point was C# is not less flexible because
>it allows pointer tricks, ...

>
.. and your point is misplaced because it is largely not the ability to
perform "pointer tricks" that makes C++ more flexible or more powerful.
>
Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.)

-- which C# is not

Hm, why ? Singularity / Cosmos are operating systems in C#. The
MicroFramework targets embedded devices.

-- but on most modern architectures (with
hardware memory management and address remapping) C++'s addresses don't
correspond to meaningful physical memory addresses anyway.
>
No, pointer manipulation is not what we're discussing, here.

O.k. pointer manipulation is the main task of C ;-).

[...]
There's nothing obscure about TMP. It's what makes the C++ standard

Hm, which C++ standard library is using meta templates ? IIRC Tr1 will
use them, boost library uses them but the STL ?

library so hugely powerful, it's what makes some of the amazingly useful

Which powerful standard library in C++ can I use for file operations ?

libraries in, for example, Boost possible.

Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.

And for example I dare to say that boost::function has a higher
overhead, than C# delegates.

Modern C++ code is built on
templates and it makes the language hugely more powerful than a

I thought it to be so too. I have implemented discriminated unions, used
type lists as they are in Loki for example and all the nice stuff.
What I got was unreadable, hard to debug and bloated code which needed a
very long time to compile.

The one compiler emitted code with a size of 3MB, the other one compiled
the same sources to 6MB.

After I had replaced all the TMP stuff by generated code the code size
could be reduced to 1MB.

classical OOP language like C# or Java could ever hope to be. Even if a
C++ programmer never writes a single template in his whole life he has
all the power of those libraries to draw upon.

Could you give me an example (part of a library), which is more powerful.

>>more strictly, to provide a plugin replacement for Java

>That's new. By the same token C++ was what to C?

>
C++ is based on C, but is not a simple replacement. The syntax of C++ is
almost a proper superset of that of C (i.e. most, but not all C source
will compile correctly if fed through a C++ compiler) with new semantics
and new functionality that represent an evolutionary increase in
flexibility and power.

But C++ inherited the worst from C - macros.

C# is based on Java. It has a slightly different syntax and a different
set of runtime APIs, but it is semantically very similar -- a little
better, because some of the mistakes of Java were not repeated, but
largely similar. Where is the evolutionary advance here? Nowhere.

- LINQ
- Delegates
- Library, which isn't bound to a single language
- Lambda expressions
- Implicit typed variables
- and many more

C++ will get some of these too, but then the argument that C++ hasn't
invented these could be used too.

>It's time to let go of C++. Really, it is. It's done for.

>
You really have no idea.

Hm, I once was a die hard C++ developer and argued the same way. But
today I'm not that sure about C++ and it's future.
I would prefer >every time< a native C# or would prefer the 'D'
language, if it would be better supported by most of the commercial
developer tools and could (directly) compile (old) C++ code.

Have you used another language than C++ too, to make a good comparison ?

I don't want to start a language war - better said continue one. But I
too think the evolution of C++ is currently too slow and heading in the
wrong direction, since modules in C++ are still delayed. If I compare
what abstraction level I can reach for example with F# and how I'm still
able to use my C# code easily, I don't think that C++ is still the

>only< way to go.

Cheers,
Daniel.

Cheers,
Andre

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

Andre Kaufmann wrote:

Daniel James wrote:

>Yes, being able to manipulate machine addresses through pointers may
>make C++ a suitable choice for very low level code (firmware, drivers,
>etc.)

>

>-- which C# is not

>
Hm, why ? Singularity / Cosmos are operating systems in C#. The
MicroFramework targets embedded devices.

An desktop/server OS is huge today.

Large parts of an OS can be written in managed code.

But some things has to be written in unmanaged code.

I don't know how much. Maybe 5%.

Even Singularity has a small amount of C++ and assembler.

If we go to embedded devices with much less features then I would
expect the percentage to go up.

And do not get me wrong - I am expecting the next major OS to have
huge part written in managed code. But as expressed in another
subthread - we may have to wait some time for the next major OS.

Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.

Compilation speed is usually not important.

>C# is based on Java. It has a slightly different syntax and a
>different set of runtime APIs, but it is semantically very similar --
>a little better, because some of the mistakes of Java were not
>repeated, but largely similar. Where is the evolutionary advance here?
>Nowhere.

>
- LINQ
- Delegates
- Library, which isn't bound to a single language
- Lambda expressions
- Implicit typed variables
- and many more

Actually the Java library is not bound to the Java language. You
can use it in Ada (jGnat), Python (Jython) etc..

Arne

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Re: C# vs. C++

David Wilkinson wrote:

C++/CLI as a first class .NET language does indeed appear doomed. Maybe
using C++ for .NET was a bad concept from the beginning, or maybe it was
done in by the flawed initial version of MC++. But, anyway, it seems dead.
>
C++/CLI is great for inter-op, but that is a limited market compared to
all the things that C# can do in .NET.
>
But native C++ lives on, both as a cross platform language, and in many
MFC/Win32 applications that are never going to switch to .NET. The
Visual C++ team is strongly committed to improve the native coding
experience in the next version of Visual Studio, after many years of
neglect.

I tend to agree.

People that want to write managed code chose C# instead of C++/CLI. It
is simply easier.

C++ will most certainly live on for many years.

I am a bit skeptical about MFC though. I think MFC will be
squeezed hard by .NET in the next 10 years. As the UI's need
to get a major rewrite then the apps will switch to .NET !

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

Daniel James wrote:

In article news:<48603eff$ 0$90276$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

>>I'd call that a positive result! Certainly better than getting 50
>>mediocre programmers.

>Seen from a puristic point of view I will agree. But there
>is this aspect of the world called money - we need millions
>of programmers to code business apps.

>
10 first class programmers will do more useful work in less time than
50 mediocre programmers ... and you will get fewer bugs.
>
In a world with concerns such as money you can't afford the mediocre.

If you look out in the real world, then you will see that
is not the general opinion.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

RFOG wrote:

Then, Alvin, next Windows will be done in C#?

Next OS from MS could very well be done in C#.

But don't hold your breath until it hits the streets.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: C# vs. C++

Daniel James wrote:

In article news:<485eee18$ 0$90272$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

>C# also has abstract classes and even though abstract classes can
>be used instead of interfaces, then interfaces especially when
>combined with the only inherit from one class but implement
>multiple interfaces rules really guide users towards good
>OOP style.

>
I think your notion of "good OOP style" is misplaced. You are saying
what Java programmers have been saying that for some time -- because
Java doesn't give them any choice.
>
You are, of course, free to follow that convention in C++ -- but if you
do so you will be limiting your design choices.

Good OOP is about limiting choices. You encourage or force
developers to do things the right way.

There is nothing
inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.

Multiple inheritance has a rather bad track record.

Arne

[Pavel Minaev]

Re: C# vs. C++

On Jun 25, 7:12 am, Arne Vajhøj <a...@vajhoej.d kwrote:

inherently wrong with allowing a class to inherit from multiple
concrete base classes, and doing so can be a useful way to encapsulate
common aspects of behaviour shared by several classes. This can
simplify design and reduce code sizes.

>
Multiple inheritance has a rather bad track record.

A correction: _implementation _ multiple inheritance _in C++_ has a
rather bad track record. Implementation MI can work just fine if
properly done - Eiffel is a testament to that.

Even so, give me interfaces and syntactic sugar to delegate their
implementation to a wrapped object over implementation MI any day. The
problem is, C# has neither, and writing all those one-liner methods
that just pass the arguments on is tedious. Hm, perhaps it's worth
adding the appropriate feature request to VS Feedback.

[Cor Ligthert [MVP]]

Re: C# vs. C++

cj,

As I often have written

VB for Net and C# are both the children of C++ and VB6.

(The VB6 part will probably be denied by people not knowing VB).

Although there is never made a VB6 for Managed code while that is there for
C++, what is of course helpfull to use both Com and Net programming, as was
often asked by dyhards from VB6, is C# made for developping in an IDE, while
C++ still is based to program using by instance a notepath.

Cor

"cj" <cj@nospam.nosp amschreef in bericht
news:uKLx1Px0IH A.6096@TK2MSFTN GP06.phx.gbl...

>I don't want to start a war but why would I choose one over the other?
>First and foremost I need to keep in mind marketability of the skill and
>the future of the language.
>
I'm getting the feeling I'll be moving from VB to one or the other. I
have some say on which but perhaps not the final decision. I have used C
and C++ a little bit years ago. I have no experience in C#. I don't
expect it to be that difficult but I hate remembering the idiosyncrasies
of too many languages so I'd like to pick one C# or C++ and make the right
choice.

[RFOG]

Re: C# vs. C++

"Arne Vajhøj" <arne@vajhoej.d kescribió en el mensaje de noticias
news:4861b6ba$0 $90275$14726298 @news.sunsite.d k...

RFOG wrote:

>Then, Alvin, next Windows will be done in C#?

>
Next OS from MS could very well be done in C#.
>

We have a phrase: "confía en Dios y no corras", that will be translated as
"be confident with God and don't run".

Of course, C# can deal with LDT, GDT, vector interrupts, rings, direct
hardware access and of course microprocessors executes MSIL directly(*).

But don't hold your breath until it hits the streets.
>

:-)

Arne

(*) Please, read as a irony.
--
Microsoft Visual C++ MVP
=============== =========
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
=============== =============== ==========
Cualquier problema sencillo se puede convertir en insoluble si se celebran
suficientes reuniones para discutirlo.
-- Regla de Mitchell.

[Daniel James]

Re: C# vs. C++

In article news:<4861b785$ 0$90275$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

Good OOP is about limiting choices.

No it isn't. It's about a certain kind of encapsulation.

Using OOP is itself a design choice -- a good one in some cases and a
poor one in others.

You encourage or force developers to do things the right way.

Encouragement and forcing are very different games. In solutions that
lend themselves well to OOP the benefits to be gained from OOP are
encouragement enough -- no need for the language to force the issue.

If your solution is not one that naturally lends itself to an OO
approach then forcing people to use a language that steers them
singlemindedly along an OOP path will only engender resentment and bad
programming.

Multiple inheritance has a rather bad track record.

It's certainly easy to use MI badly -- especially in C++, which doesn't
believe in restricting choices unnecessarily -- but that doesn't mean
that isn't a useful technique, or that it can't be used productively
and well.

Cheers,
Daniel.