Why exactly is C# better than C++ (was Re: Up to date MFC Book)

[Bruno van Dooren [MVP VC++]]

Managed C++ can do everything C# can and more.

MC++ is a thing of the past. It was a short term fix and apparently not
good
enough for MSFT. Take a look at CLI.

It wasn't good enough for lots of people.
The syntax was plain horrible, and the same piece of code could be different
things, depending on how classes, variables etc were declared. * and & were
use for managed and unmanaged pointers and references, so mixed mode code
could get very messy very quickly.
CLI is much more understandable.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Tom Serface]

No doubt about that. I'm hoping that helps make it more widely accepted.

Tom

 

[Ajay Kalra]

I did lot of object model development for an existensible app (all in C++).
It wasnt too bad but I could see what a nightmare it is compare to regular
C++ programming. Then I went to the client side to do test it using VB and
it was a piece of cake. Same work in MFC/ATL was comparably very complex.
COM development in general is not easy but the benefit it offers (at least
when it came out) were very good. I still like VBA type support in unmanaged
app.

 

[Volker Hetzer]

The biggest criticism I have about C# is the difficulty of deterministic
finalization, which is solved elegantly in Managed C++ using ~Class() and
!Class(). So for me, it is Managed C++ 1, C# 0.

Ditto for me. Plus I can do unmanaged, compiled apps when I need raw speed.

Lots of Greetings!
Volker

 

[Bruno van Dooren [MVP VC++]]

The biggest criticism I have about C# is the difficulty of deterministic

Ditto for me. Plus I can do unmanaged, compiled apps when I need raw
speed.

Except that Managed C++ is as dead as the dodo.
Unless of course you mean C++/CLI, which is alive and kicking.

Still, I only use C++/CLI for interop code. If I need to write an app or lib
that lives entirely in the .NET realm, I use C#.
C# intellisense works always, and the syntax is less bothersome.
Yes, I love C++. more so than C# or any other language, but C# rules when it
comes to whipping something together quickly.

For me, it is not C++ OR C#. it is C++ AND C#.
If you already know C++, C# is dead easy to learn.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Tom Serface]

Hi Bruno,

I know and you know that MC++ was superceded by C++/CLI (a more universal
standard) and that the CLI was implemented (in this case) to perform like
the CLR, but I think most of the world still equates the two. That's part
of the problem with pardigm shifts. I think part of the allure of C# is it
is so easy to learn. Nish's early article on the subject is pretty good:

http://www.codeproject.com/managedcpp/cppcliintro01.asp?df=100&forumid=39814&exp=0&select=998071

Tom

 

[Guest]

For me, it is not C++ OR C#. it is C++ AND C#.
If you already know C++, C# is dead easy to learn.

Even if you don't learn C#, an even halfway-experienced C++ developer can
read C# code samples and have no difficulty understanding how to get C++/CLI
to accomplish the same basic thing.

My biggest gripe with C# is all the little minor syntax differences between
it and C++...trips me up all the time.

Sean

 

[Carl Daniel [VC++ MVP]]

My biggest gripe with C# is all the little minor syntax differences
between
it and C++...trips me up all the time.

.... but then, many would argue that C# was designed to be an easy transition
from Java, not from C++. I totally agree though - for me now, it's just the
opposite: I've written so much C# that when I go back to C++ I'm constantly
using '.' where I should have used '::' or '->'.

-cd

 

[Tamas Demjen]

The biggest criticism I have about C# is the difficulty of deterministic
finalization, which is solved elegantly in Managed C++ using ~Class() and
!Class(). So for me, it is Managed C++ 1, C# 0.

C++/CLI, you mean, because Managed C++ doesn't have deterministic
finalization, C# and C++/CLI do. In fact, C# has exactly the same
feature as C++/CLI, except with a different syntax. I personally prefer
the C++/CLI stack notation:

ManagedClass c;
c.Member();

C# does the same thing with the using keyword, which is one extra
keyword to write, one more thing to remember, thus it's less elegant,
but functionally they're still equal.

Some argue the using syntax only works for ocal objects, but this is
exactly the same in C++/CLI. You can't use the stack syntax to make ref
classes behave like ISO C++ classes. ref classes are not value types,
and value types are not objects but pure byte-streams. The C++/CLI stack
syntax makes absolutely no benefit when you need to store ref classes in
a container:

List<RefClass> list; // doesn't work
List<RefClass^> list;
// compiles, but no deterministic destruction for its members

If you wrap unmanaged classes into managed code using C++/CLI,
deterministic destruction is very important (as unmanaged memory is not
garbage collected), but the stack syntax only works for local variables
and class members. A reference counted auto pointer would come handy,
something like boost::shared_ptr, but it can't be implemented, not even
in C++/CLI. The goal would be to write the managed equivalent of
vector<shared_ptr<T> >, but it doesn't seem to work. If shared_ptr is a
value class, it can't have a destructor, so deterministic finalization
is ruled out. shared_ptr has to be a ref class in order to have its
destructor, but then it has the same old problem, namely that .NET
collections are not deterministic (deleting an item doesn't guarantee a
Dispose on it). So the first step would be to create such containers
that store IDisposable objects in a way that guarantees deterministic
finalization for all of its members. Such containers might exist, I'm
not sure. Fortunately it's not too hard to implement such containers,
even by inheriting from List<T>.

Tom

 

[David Ching]

Hi Bruno,

I know and you know that MC++ was superceded by C++/CLI (a more universal
standard) and that the CLI was implemented (in this case) to perform like
the CLR, but I think most of the world still equates the two.

I meant CLI (available with VC2005), not the previous MC++. If MS had
released CLI instead of MC++, C++ would probably be a lot more popular way
to program .NET because C# would not then have been such a clearly superior
language.

-- David

 

[David Ching]

List<RefClass> list; // doesn't work
List<RefClass^> list;
// compiles, but no deterministic destruction for its members

Oh boy. I had thought that if I implemented both ~Class() and !Class() in
CLI (yes, CLI, not MC++), that I didn't have to worry about anything. It
would just work. If I have to go through my classes and figure out what are
ref objects or not, that kind of is a deal breaker, isn't it? Either it
works 100% without thinking, or it doesn't. Can you verify that it doesn't?

Thanks,
David

 

[Tom Serface]

No doubt about that. I hope it can regain some ground now.

Tom

 

[Daniel James]

Still, I only use C++/CLI for interop code. If I need to write an app or lib
that lives entirely in the .NET realm, I use C#.
C# intellisense works always, and the syntax is less bothersome.
Yes, I love C++. more so than C# or any other language, but C# rules when it
comes to whipping something together quickly.

But that choice is based on the quality and availability of tools, not of the
language. What you're really saying is that we need C++ tools that are as good
as the C# ones.

Cheers,
Daniel.

 

[Bruno van Dooren [MVP VC++]]

Still, I only use C++/CLI for interop code. If I need to write an app or

But that choice is based on the quality and availability of tools, not of
the
language. What you're really saying is that we need C++ tools that are as
good
as the C# ones.

C++ is a powerful tool that can do almost anything you want, very
efficiently.
But it is not an easy language to learn. Mastering C++ to the level of an
expert can take many years, and even then there will be areas that you are
probably not proficient with.
On top of that, the syntax has to allow for all this power, so it has to
provide a rich set of semantics.

Trying to dumb down C++/CLI syntax to enable the simplicity of C# is
impossible without taking away the power for full 'it just works'
interoperability.

Another very important factor is also that you have to transfer maintenance
to other programmers.
Even after a few short years, I suspect there are more experienced C#
programmers than C++ programmers.
If I create a simple program in C++, my client would need to have a C++
programmer to maintain it.
if I create the same program in C#, it will be much easier for my client to
maintain it.

I do not believe in the 'one ring to rule them all' approach.
Different tools are meant for different jobs.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Daniel James]

[I wrote]

What you're really saying is that we need C++ tools that are as
good as the C# ones.

C++ is a powerful tool that can do almost anything you want, very
efficiently. But it is not an easy language to learn.

I'm having difficulty seeing how you think your answer addresses the point I
made.

When I wrote "tools" I didn't mean the language or even the compiler, I meant
things like form designers, refactoring tools, database bindings, code
generators -- all of which exist for C# (and e.g. Java). These tools don't
exist -- or are much more rudimentary -- for C++.

IMV the tools vendors -- in this case Microsoft -- would have done better to
spend their development budget providing good tool support for an existing
language (C++) that inventing a new language that nobody needs.

Mastering C++ to the level of an expert can take many years, and even then
there will be areas that you are probably not proficient with.

'Mastering' the whole of C++ could take a lifetime, but acquiring a
sufficiently good working knowledge of the language to write useful
application code is not so daunting. Sure, there are seldom-explored corners
of the language where Powerful Stuff happens -- but those corners are the
realm of library writers, and ordinary folk need only go there out of
interest, to satisfy curiosity, or to pursue obscure bugs.

I don't agree that C++ is too intimidating for regular application
programmers -- if these people are smart enough that you trust them to write
software for you AT ALL then they will be smart enough to use C++
productively and to benefit from its greater power.

Look at the way C++ is presented in modern introductory works like Koenig &
Moo's /Accelerated C++/ or Francis Glassborow's /You Can Program in C++/. the
language is presented as an immediately accessible, very usable language. The
extensive use of the standard library ensures that power and safety of the
language are exploited, while keeping the code presented to the user simple
and understandable. C++ is NOT a black art.

Good programming requires good programmers. If your programmers aren't good
you won't make them any better by giving them an "easy" language to use.
They'll just be very productive at writing bad code.

I agree that, as things stand, good programmers may be more productive at
some tasks using C# than using C++. That's not a failing of C++, it is (as I
said) a failing of the tool support provided for/with C++ -- the form
designers, refactoring editors, etc.. Those things improve productivity by
taking some of the 'leg-work' out of programming, but they don't make one a
better programmer, or improve the quality of one's code.

As I said: what the industry needs most is high quality productivity tools
for existing languages.

I do not believe in the 'one ring to rule them all' approach.
Different tools are meant for different jobs.

If by "tools" you mean languages I agree: there are specialized languages
that are particularly suited to certain jobs, and they are generally better
for those jobs than general-purpose languages. However C++ and C# are both
general-purpose languages without any particular niche specialization. They
are good for the same things, and I see no reason for anyone to need to use
both -- C++ covers all the bases.

Cheers,
Daniel.

 

[Bo Persson]

[I wrote]

What you're really saying is that we need C++ tools that are as
good as the C# ones.

C++ is a powerful tool that can do almost anything you want, very
efficiently. But it is not an easy language to learn.

I'm having difficulty seeing how you think your answer addresses the
point I made.

When I wrote "tools" I didn't mean the language or even the
compiler,
I meant things like form designers, refactoring tools, database
bindings, code generators -- all of which exist for C# (and e.g.
Java). These tools don't exist -- or are much more rudimentary --
for
C++.

C# and Java are proprietary languages with a strong economic backing,
and a lot of marketing resources. C++ has nothing of that.

Considering that, it is amazing how well C++ does on its own.

IMV the tools vendors -- in this case Microsoft -- would have done
better to spend their development budget providing good tool support
for an existing language (C++) that inventing a new language that
nobody needs.

They don't seem to think so. By pushing C# and .NET tools, for free
even, they believe they will catch the audience for their platform.

Why provide good tools for (possibly portable) code in C++, when they
have no control over it?


Bo Persson

 

[David Wilkinson]

Daniel James wrote:

'Mastering' the whole of C++ could take a lifetime, but acquiring a
sufficiently good working knowledge of the language to write useful
application code is not so daunting. Sure, there are seldom-explored corners
of the language where Powerful Stuff happens -- but those corners are the
realm of library writers, and ordinary folk need only go there out of
interest, to satisfy curiosity, or to pursue obscure bugs.

I don't agree that C++ is too intimidating for regular application
programmers -- if these people are smart enough that you trust them to write
software for you AT ALL then they will be smart enough to use C++
productively and to benefit from its greater power.

Look at the way C++ is presented in modern introductory works like Koenig &
Moo's /Accelerated C++/ or Francis Glassborow's /You Can Program in C++/. the
language is presented as an immediately accessible, very usable language. The
extensive use of the standard library ensures that power and safety of the
language are exploited, while keeping the code presented to the user simple
and understandable. C++ is NOT a black art.

I agree with you here. Standard C++ is not too difficult to learn as a
first language, if it is presented carefully. In many ways it is easier
than C, because the standard library is much easier to use than all the
pointers in C.

The trouble is that C++/CLI, on the other hand, is a very complex
language. Although the syntax is improved, it still looks like what it
is: two languages with very different object models slapped together.
For a novice programmer wanting to write .NET code, I would say it is
close to impossible (the continuing lack of books does not help,
either). So beginning programmers will start with C#, and perhaps never
move to C++. Only someone who already knows C++ will not be completely
overwhelmed by C++/CLI. Right now that's us. But who will it be in 20 years?

David Wilkinson

 

[Ole Nielsby]

[...] I love C++ [...] but C# rules when it
comes to whipping something together quickly.

But that choice is based on the quality and availability of
tools, not of the language. What you're really saying is
that we need C++ tools that are as good as the C# ones.

But tool design and language design are related matters.
You cannot simply take the tool design techniques for
C# and apply them to C++.

I think the notion that tools and language design should
be co-designed was introduced with Ada. The idea
was, tools should be specified along with the language
and both he designed to enforce or assist in creating a
standard coding style.

Stoustrup took another stance, emphasizing the free
choice of tools and methods.

This freedom has a cost: if you unleash your dog you
don't know where it will go. And what RAD tools do
is essentially prediciting the moves of us code dogs,
and putting us on roller scates and gently kicking our
behinds to get us moving faster.

Consider a generic class in C#: as you type it, you
constrain the parameter types with where-clauses.
So, when you get to the code, intellisense knows
what methods are available on these types though
they aren't bound.

It's hard to see how intellisense could accomplish
this in a C++ template. How can it help you select
a method name if the object could belong to just
about any class?

I'm not saying C++ programmers are wild dogs that
should be punished with bad tools for not wearing a
leash and staying on the pavement. I'm just saying it
might not be possible to get the same level of RAD as
with more restrictive languages. Roller skates are fine
on the pavement, but there is a reason Lassie doesn't
wear them.

Ole N.

 

[William DePalo [MVP VC++]]

IMV the tools vendors -- in this case Microsoft -- would have done better
to
spend their development budget providing good tool support for an existing
language (C++) that inventing a new language that nobody needs.

IMV, there is a huge gap between the complexity of the C++ language and the
ability of the average devleoper to handle that complexity. In addition,
there is a large gap between the expectations of enterprises which employ
developers and the "productivity" of the average C++ developer.

I put "productivity" in quotes because in a lot of shops the only thing that
matters in time to competion. Things like quality, robustness,
extensibility, performance etc don't enter into the equation.

In a real sense C# is not better, just better suited to the time.

Regards,
Will

 

[David Ching]

Look at the way C++ is presented in modern introductory works like Koenig
&
Moo's /Accelerated C++/ or Francis Glassborow's /You Can Program in C++/.
the
language is presented as an immediately accessible, very usable language.
The
extensive use of the standard library ensures that power and safety of the
language are exploited, while keeping the code presented to the user
simple
and understandable. C++ is NOT a black art.

Absolutely. I will probably step on some toes here, but I believe libraries
such as Boost and STL that use templates to the extreme and present
unnatural syntax to the programmer are examples of what give C++ it's
"hard-to-use" bum rap.

Why anyone would want the upcoming STL.NET is a mystery to me.

I agree that, as things stand, good programmers may be more productive at
some tasks using C# than using C++. That's not a failing of C++, it is (as
I
said) a failing of the tool support provided for/with C++ -- the form
designers, refactoring editors, etc.. Those things improve productivity by
taking some of the 'leg-work' out of programming, but they don't make one
a
better programmer, or improve the quality of one's code.

I can't wait for the C++ tools to catch up with C#. Then again, too many
programmers don't use the tools already available. I keep showing Visual
Assist to people, and they just don't get it. These are the people that
change the indentation of a block of code by manually typing or deleting
tabs of each line. And don't use the "Find matching brace" function to
figure out compiler errors.


Cheers,
David