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

[David Ching]

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?

But C++/CLI is tied to Microsoft as much as the other languages.

-- David

 

[David Ching]

.Net essentially has killed COM and for good reason.

Unfortunately, not fast enough. To make IE controls or WMP plug-ins, you
still need COM. Although maybe you can create a .NET control that emulates
COM. I think that's what Lookout did for their Outlook plug-in (that was
acquired by Microsoft and is now free... it is a really great "google for
Outlook" plug-in).

-- David

 

[David Ching]

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?

Upon re-reading what Tamas wrote, it seems you only have to worry about
deterministic finalization of objects stored in .NET collections, like
lists. If that's the case, it isn't as serious a problem as I had thought.
Most objects in collections don't hold resources open using the "Resource
Acquisition is Initialization" which is primarily what I want to use
deterministic finalization for.

Thanks,
David

 

[David Ching]

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.

Sort of like saying, let's take back the rope, we've seen too many C++
programmers hang themselves with it, no? I've seen it happen too. There
are too many codebases where project lead wannabes wanted to "experiment"
with the latest template craze and ended up with an unmaintainable mess.

-- David

 

[Bo Persson]

But C++/CLI is tied to Microsoft as much as the other languages.

And it has got better tools.


Bo Persson

 

[William DePalo [MVP VC++]]

Sort of like saying, let's take back the rope, we've seen
too many C++ programmers hang themselves with it, no?

Exactly, as to the rope. The sad reality is that there are a may application
domains for which C# is good enough.

Regards,
Will

 

[Daniel James]

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

Toll /design/ yes, but there is a core of tool /functionality/ that is
common to most languages. There's quite a large overlap between the
functionality sets programmers want/need for C# can C++ because the one is
nearly a subset of the other.

The scope of the problem may be much greater in C++ because the language is
richer and more powerful. To pick a very simple example: a refactoring
manipulation to remove a block of code from a class method and make a
separate function of it. In C++ or C# you can simply cut/paste the lines of
code and create a new member function (which may accept as parameters some
of the quantities used in the code block). In C++, though, it might be more
appropriate to make a non-member non-friend function to do the job (and
maybe place it in an unnamed namespace in the compilation unit to avoid
flooding the global namespace) ... of if a similar refactoring is to be
done in several classes it might be more useful to make a function
template.

Yes, tools could do so much more in C++, but there's a useful subset of the
functionality that is just the same as what is done in C# (or Java).

How you write those tools may be very different, how you use them may not
be.

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.

It's an interesting idea, but until the language has been used for a while
and people have solved real-world (and not-so real-world) problems in it
there will not be a sufficiently complete understanding of the language
idioms that work and are useful for a good toolset to be specified. How
long was it before idioms like RAII or pimpl (compilation firewall) were
recognized as standard techniques in C++? Or TMP?

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?

You can't, obviously. C++ isn't /quite/ a superset of C#.

Intellisense isn't really the sort of tool I was thinking of, though, C++
does have intellisense (though, as you point out, it has its limitations).

Cheers
Daniel.

 

[Volker Hetzer]

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

That's what I meant.

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

So far I can't see it for me. Automatic resource management is IMHO
unbeatable.

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 prototyping (and almost all our V1.0 versions) we use Tcl/Tk, although
our environment is an exceptional one.

Lots of Greetings!
Volker

 

[Volker Hetzer]

David Ching wrote:
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.

The using keyword is stupid. Why do I have to artificially nest all
objects?

Lots of Greetings!
Volker

 

[Tamas Demjen]

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.

Theoretically your finalizer will be called -- eventually. The question
is when. Probably not for minutes to come. If Class is a critical
resource that needs to be released as soon as possible, deterministic
finalization is highly preferred.

I can show you an example when relying on the finalizer alone is
dangerous. I have an unmanaged class that represents a scanned bitmap
image, several megabytes of data per instance. I wrap that to a managed
class, which I then want to store into those unsafe .NET containers that
don't guarantee deterministic destruction. The finalizer is not likely
to be called until the system runs out of managed memory. However, the
system will run out of unmanaged memory very quickly. sizof(unmanaged
memory) = 10 MB. sizeof(ManagedClass) = 4, so the GC won't hurry with
the finalizer, it has the impression the object is very lightweight.
What it misses is that the underlying unmanaged object is very heavy.

At least in .NET 2.0 you have a way to tell the GC the weight of the
object. So ManagedClass can get the size of its underlying native
object, and let the GC know the object represents a heavy load.

Tom