how does C# compare to C++ and VB

[Daniel]

If I'm reasonably familiar with C++ and am an expert at Visual Basic, what
principles should I apply in order to understand C# so that I could more
quickly learn the language?

Daniel

 

[Daniel]

Would anyone be able to recommend a book or a web site that would help me
learn C# given my background in programming?

Daniel

 

[Arne Vajhøj]

If I'm reasonably familiar with C++ and am an expert at Visual Basic, what
principles should I apply in order to understand C# so that I could more
quickly learn the language?

You are pretty well covered with C++ and VB.

You need to study garbage collection and interfaces. LINQ if
you want the latest.

Arne

 

[Arne Vajhøj]

Would anyone be able to recommend a book or a web site that would help me
learn C# given my background in programming?

Try Profession C# from Wrox.

Arne

 

[Daniel]

What is LINQ?

Daniel

You are pretty well covered with C++ and VB.

You need to study garbage collection and interfaces. LINQ if
you want the latest.

Arne

 

[Arne Vajhøj]

What is LINQ?

http://en.wikipedia.org/wiki/LINQ

Arne

 

[Daniel]

That's what I needed to know. Thanks.

Daniel

It thinks like VB but looks like C++. That is, it is practically the same
language as VB but with a C-like syntax. It is not much like C++.

 

[Jon Skeet [C# MVP]]

There's a good book called "A Programmer's Introduction to C# 2.0." The
current version is 3.5 but there has been little change. I don't know if
the book has been updated.

Slight correction: the current version of C# is 3.0. Don't get confused
between framework and language versions :

See http://csharpindepth.com/Articles/Chapter1/Versions.aspx

(And I would disagree strongly with the idea that there's been "little
change" between 2.0 and 3.0. LINQ is a pretty massive change, IMO...)

 

[Jon Skeet [C# MVP]]

If I'm reasonably familiar with C++ and am an expert at Visual Basic, what
principles should I apply in order to understand C# so that I could more
quickly learn the language?

Do you mean you're an expert at "old" VB (version 6 or earlier) or the
..NET version (now no longer called VB.NET, unfortunately)? If you
already know the .NET framework you'll get to grips with C# a lot more
easily than if all your experience is with "classic" VB.

 

[Ben Voigt [C++ MVP]]

How did you get reasonably familiar with C++ without making a
substantial investment in it?

Seriously though, I think you're overthinking things. C#, C++, and
VB all have substantially the same kinds of features. They are more
like each other (especially C++ and C#) than they are like most other
languages. Each language has some specific differences, and some

C# is far closer to Java and VB.NET than it is to C++. C++ has
substantially the same OOP features as C#, but templates can do a not of
things generics can't, other features are more powerful as well, and as a
result C++ supports modern non-OOP programming styles (TMP for example).

people will swear one is broadly superior to another, but on the
whole -- and especially in the context of .NET programming -- it
really just comes down to your preferences.

I strongly prefer C# over VB and C++, at least for .NET programming,
and I have my reasons for that. But I don't think I've written any
C# programs that couldn't have been written in either of the other
languages, and 80-90% of the code would have been pretty much the
same even.

I agree with this. Writing .NET code with C++/CLI is really sluggish
compared to C#, at least once you add in the Visual Studio environment and
add-ins like Resharper/Refactor Pro/VAX. Making tools for C# is just much
much easier than doing the same for C++.

 

[Ignacio Machin ( .NET/ C# MVP )]

If I'm reasonably familiar with C++ and am an expert at Visual Basic, what
principles should I apply in order to understand C# so that I could more
quickly learn the language?

Daniel

Progamming principles

Joke apart, the languages are only a mean to express concepts. If you
are familiar with the OOP concepts you will have no problem in C#

 

[Ben Voigt [C++ MVP]]

[...]

Seriously though, I think you're overthinking things. C#, C++, and
VB all have substantially the same kinds of features. They are more
like each other (especially C++ and C#) than they are like most
other languages. Each language has some specific differences, and
some

C# is far closer to Java and VB.NET than it is to C++.

I agree whole-heartedly about being closer to Java. But the OP
didn't ask about Java.

I disagree on the VB/VB.NET point, but I guess that's a matter of
opinion so not entirely unexpected. In spite of some fundamental

They don't "look" alike, but the actual feature matrices for VB.NET and C#
are almost identical. VB has exception filters that C# doesn't. I suspect
we'd be hard-pressed to list more than 6 more differences.

conceptual differences between C++ and C#, I find moving back and
forth between those languages much easier than moving back and forth
between C# and VB.NET and so to me they are more similar to each
other than C# is to VB.NET (and this is especially true if only
limiting the comparison to C++/CLI rather than C++ more generally).


And generics can do things templates can't. They are similar, but not
equivalent.

Generics can do things that the Microsoft C++ compiler can't do with
templates, because Microsoft C++ doesn't support the C++ standard
(specifically export). Since I'm aware of only one C++ compiler that does
implement export, your statement is correct for all practical purposes.

However, the Microsoft C++ compiler does support generics.

IMHO it's inflammatory to describe one language as "more powerful" as
compared to another, and in most cases (including this one) decidedly
inaccurate.

Would you disagree that C++ is more powerful than C? It's practically a
100% superset. The same is true of C++ vs C#, although they're a lot closer
in capability. Actually one of the big points in favor of C# is that it's
controlled by a single company, so new features reach developers a lot more
often, in many cases earlier. C++03 beats C# 1.x which was available at the
same time. And C++0x will be a near superset of whatever version of C# is
out at the same time, probably 4.x

Of course, if by "other features are more powerful" you did not mean
to imply that C# does not also have "more powerful" features, then my
concern is misplaced. But that's not how I read your statement.

C# has some of these powerful features that don't have a direct equivalent
in C++. There's some very nice syntactic sugar, like anonymous methods
(although closures are coming soon to C++ as well). But none of them
respresent a truely different paradigm, such as TMP is, so ultimately most
of the reasons to choose C# over C++ (such as garbage collection, runtime
code generation, etc) come from either lack of features (making the language
easier to learn) or the CLR, which isn't a feature of any particular .NET
language. These can be accomplished in C++ by using an appropriate library
and runtime, one of which, thanks to the /clr option, is .NET itself.

 

[Jon Skeet [C# MVP]]

They don't "look" alike, but the actual feature matrices for VB.NET and C#
are almost identical. VB has exception filters that C# doesn't. I suspect
we'd be hard-pressed to list more than 6 more differences.

I'm game to see if we can manage it between us. No cheating and looking
it up though. If anyone fancies verifying my guesses, however, that's a
different matter

VB 9 has XML literals; C# doesn't.

C# 3 has lambda expressions with block bodies (i.e. multiple
statements); VB 9 only allows lambdas of a single expression, IIRC.

VB 9 allows mutable anonymous types; they're always immutable in C#.

VB allows late binding; C# doesn't (yet).

C# has pointers and allows unsafe code. I'm not sure whether VB has
this yet.

C# has iterator blocks; I don't believe VB does.

That's 6 - can anyone add to it to go to *more* than 6?

 

[Ben Voigt [C++ MVP]]

[...]
That's 6 - can anyone add to it to go to *more* than 6?

Sure, I think there's at least a couple of obvious ones:

-- VB has a concept of a "default instance". That is, if you
refer to a type by name rather than an explicitly allocated instance,
VB creates the instance for you. I don't know VB well enough to know
if that's a language feature or something special to the Form class,
but it's certainly something that happens in VB but not in C#.

-- The "With" statement.

-- VB's support for declaring an event handler that specifies what
event it's actually handling (in C# you have to subscribe the event
explicitly).

Oops, sorry. That's three.

These seem to me to be more syntactic than anything, unlike the ones Jon
came up with, which for the most part cannot be duplicated in the other
language at all.

[snip]

What does surprise me is that Ben can on the one hand argue that
VB.NET and C# are closer to each other than C# is to C++, and yet on
the other hand argue that C++ is essentially a "superset" of C#. At
best, C++ can only be thought of as a superset of C++ if one looks
only at the Microsoft C++/CLI implementation of C++ (reasoning that I
find a bit disingenuous), but even if one does, the implication of
that assumption is that C++ is just as similar to VB.NET as C# is.

Let's use "natural numbers", "cardinal numbers", and "real numbers". Would
you dispute that "natural numbers" are most similar to "cardinal numbers",
but "real numbers" are a superset of both?

Similarly, C++ is an almost 100% superset of C89, yet C89 and C99 are far
closer to each other in every respect than to C++.

But as I've said before, personally I find all three languages
functionally to be basically equivalent. This entire discussion is
starting to smack of "my langauge is better than yours" and I think
that's a silly discussion to have. Religious arguments of that
nature don't interest me much.

I'd suggest you read some of Stroustrup's papers to understand just how far
beyond simple OOP C++ can go. Yes, if you restrict yourself to thinking of
the approach you'd take with C#, then all three are basically equivalent.
But C++ enables other approaches entirely that C# and VB have no way to
represent.

 

[Arne Vajhøj]

Slight correction: the current version of C# is 3.0. Don't get confused
between framework and language versions :

See http://csharpindepth.com/Articles/Chapter1/Versions.aspx

(And I would disagree strongly with the idea that there's been "little
change" between 2.0 and 3.0. LINQ is a pretty massive change, IMO...)

I really think they should have kept the .NET and C# version
numbers in synch. It would avoid much confusion.

Arne

 

[Ben Voigt [C++ MVP]]

[...]

Oops, sorry. That's three.

These seem to me to be more syntactic than anything, unlike the ones
Jon came up with, which for the most part cannot be duplicated in
the other language at all.

On "With" I see your point (though I'm not sure why it's
relevant...it's still a real difference between the languages). On
the other two, I don't see those as any more "simply syntactic" than
for example VB's lack of multi-statement lamba's (which are at least
partially duplicated simply by putting the code in a separate method,
just as anonymous methods themselves don't do anything you couldn't
write explicitly if you wanted to), or iterator blocks (again, it's

Ahh, but lambda's can be traversed as a parse tree instead of turned into a
delegate. The workaround of putting the code in a separate method doesn't
support that.

just "compiler magic"...you could implement the same functionality
more explicitly in VB.NET if you like, just without any help from the
compiler).

Forgive me if I fail to see the point of the analogy. The "superset"
and "subset" relationship mathematics between the kinds of numbers you
describe is well-defined. Not so with computer languages, nor the
idea of "similar".

So you snipped the (self-evident) example using computer languages. In any
case, "superset" does not imply "similar".

The problem here is (I believe) is a fundamental difference in the
way we perceive the concepts of "similar".

[...]
I'd suggest you read some of Stroustrup's papers to understand just
how far
beyond simple OOP C++ can go. Yes, if you restrict yourself to
thinking of
the approach you'd take with C#, then all three are basically
equivalent. But C++ enables other approaches entirely that C# and VB
have no way to represent.

Why not provide an example? I'm not going to go off picking to read
random writings by the designer of C++ in the hopes of figuring out
what you mean. If you think there's such a clear difference, it
should not be difficult to present a practical example clearly
demonstrating how C++ is "more powerful" in a way that C# cannot be.

Well, there are quite a few examples here:
http://www.codeproject.com/KB/cpp/crc_meta.aspx

But a simple one you should be very familiar with is
EqualityComparer:efault

Just you try to make a Dictionary in .NET that supports *any* Key class or
struct without a virtual call to test equality. I suspect that the .NET JIT
is coded to specifically recognize Dictionary or at least
EqualityComparer:efault and perform a spot optimization, because doing the
virtual call would kill performance. C++ templates easily implement the
different comparison cases at compile-time with no runtime overhead, using
type traits and partial specialization.

Or try making a cache that uses a different data structure for small objects
vs big ones, without the consumer having to select the right one.

Multiple inheritance isn't all that useful -- unless you combine it with
CRTP for composition of multiple behaviors. Let's say I had a word
processing control, and a derived class that implements stylus entry
(handwriting recognition). And another derived class that provides skinning
(i.e. select a color scheme). And another one that automatically backed up
the users' data periodically in case of power loss while the app is open.
And another that implements text-to-speech. In C#, is there any way to get
more than one of these behaviors at the same time without reimplementing the
functionality? Not without modifying one of the components to inherit from
a different one. In C++, if you implement CRTP composition or even template
parameter inheritance support then you can build any combination without any
of the variants having prior knowledge of any of the others.

 

[Jon Skeet [C# MVP]]

Ahh, but lambda's can be traversed as a parse tree instead of turned into a
delegate. The workaround of putting the code in a separate method doesn't
support that.

On the other hand, lambdas with multiple statements can't be turned
into a parse tree by the C# compiler either:

Expression<Action> f = () => { int i=0; i++; }

gives:

error CS0834: A lambda expression with a statement body cannot be
converted to an expression tree

Just a minor point, and mostly irrelevant to the discussion on C++
though.

 

[Jon Skeet [C# MVP]]

I really think they should have kept the .NET and C# version
numbers in synch. It would avoid much confusion.

Agreed. Although as I blogged earlier tonight, publishers are doing
their bit to add to the confusion too, talking about "C# 2008"

 

[Arne Vajhøj]

I agree whole-heartedly about being closer to Java. But the OP didn't
ask about Java.

I disagree on the VB/VB.NET point, but I guess that's a matter of
opinion so not entirely unexpected. In spite of some fundamental
conceptual differences between C++ and C#, I find moving back and forth
between those languages much easier than moving back and forth between
C# and VB.NET and so to me they are more similar to each other than C#
is to VB.NET (and this is especially true if only limiting the
comparison to C++/CLI rather than C++ more generally).

C#<->VB.NET converters are much better than C#<->C++ converters.

Which I see as a reasonable indication of how close the languages
are.

Arne

 

[Arne Vajhøj]

"much better" == subjective, unquantified opinion.

Should be obvious to anyone with experience in the languages.

But let us find the last complete program you posted in this
group > 100 lines. I will find a converter that convert it to
VB.NET - you will find a converter that converts it to C++
(not C++/CLI), we post the two here and then people can compare.

OK ?

In any case, I'm not insisting that anyone else take the same view. My
own personal experience is irrefutable as it pertains to my own
perceptions, and that is that I find it easier for _me_ to translate
between C++ and C# than to translate between either of those and VB.NET.

YMMV, and I don't care. It doesn't have anything to do with _my_
impressions, which was all I was sharing.

Who on earth would convert manually between C# and VB.NET at all ?

Translations are very good. Usually you convert and it either just
works or you have to make a few trivial changes.

Arne