learn C++ or C#

[Daniel James]

Re: learn C++ or C#

In article news:<u0RfIKc6I HA.2060@TK2MSFT NGP02.phx.gbl>, Larry Smith
wrote:

I once met a very senior person in C++ circles (I won't mention his
name) and I asked him for his opinion. He suggested that perhaps
5% of all C++ programmers are competent.

5%? Maybe. It's certainly no more than about 10%.

The percentage doesn't change much for other languages, though, bad
programmers will write bad code in any language.

Remember Sturgeon's (second) rule.

http://en.wikipedia.org/wiki/Sturgeon%27s_revelation

Cheers,
Daniel.

[Daniel James]

Re: learn C++ or C#

In article news:<exrO6ca6I HA.2220@TK2MSFT NGP06.phx.gbl>, David Wilkinson
wrote:

But really I do not think about porting my applications any more,
because I feel that CrossOver MAC and CrossOver Linux do a pretty
good job of running Windows applications.

That's a good point -- and well made -- and if your apps are all desktop
apps then it may be a good enough solution for you. I achieve much the
same by running Windows apps in a Windows VM under linux; it means I have
to have a licensed copy of Windows to run in the VM, which you avoid by
using Crossover (or Wine), but that is not a big problem.

Many customers, though, insist on a native application and won't accept
the additional cost in hardware resources needed by either Crossover or a
VM.

In my work I have often had to share code between a desktop application
and an embedded application, so the separation between back-end logic
(ROMmable) and GUI has been very important.

Cheers,
Daniel.

[David Wilkinson]

Re: learn C++ or C#

Daniel James wrote:

Thanks for that. I had seen it before ... and I don't see anything there
that suggests that C++/CLI is "not recommended" for GUI code. All Steve
says that's at all relevant is that MS don't propose to spend time writing
GUI design tools that target C++/CLI when they already have some that
target C# and there are other things they want to spend resources on to
support C++.
>
That's a fair enough viewpoint, and the message in the blog is that MS (or,
at least, the C++ team) are following what they believe to be the wishes of
their customers in that respect.
>
That doesn't mean that they don't recommend using C++/CLI, it means that
they won't provide any tools to help you do that. That's not big deal,
really, because it doesn't actually matter what language any automatically
generated code is in -- the form designer might as well spit out a compiled
assembly as C#. Microsoft do say that the C# generated by the designers
isn't supposed to be edited by the user -- that's how they get away with
emitting such poorly structured code.
>
You don't actually *need* to have any tools to help you write GUI code,
anyway. You can do it all by hand. The form designers may save you some
time but in a large project that time is not significant, and hand-crafted
code will be better structured and more maintainable than anything that
comes from the designers.

Daniel:

Maybe I should not say "Microsoft does not recommend" then. Do you think
"Microsoft does not promote" would be more accurate? Or do you feel that is too
strong also?

I'm sure there are some advanced users who use C++/CLI to write GUI .NET
applications, but the vast majority of the C++/CLI questions I see in the
newsgroups/forums come from novices who have downloaded VC++ Express and have
found that, absent MFC, the only out-of-the-box way to write GUI applications is
to use .NET. Many of these folks, like the OP, are not even aware that the
language they are using is not C++. They have chosen C++ because the name sounds
familiar, or perhaps know it a bit already, but the vast majority of these
people would have been batter off downloading VC# Express instead. At any rate,
they are not going to be happy if the forms designer in VC++ is crippled.

But even experienced C++ users seem to be embracing C# over C++/CLI. It's not
just the designer tools; some features (such as LINQ) are not even available in
C++/CLI. It's a shame after all the effort that went into C++/CLI (after the
initial MC++ debacle), but there it is.

What's the solution? I think MS has to fully face up to the fact that VC++ is
for native code, get the IDE back to the level of usability/responsiveness we
had in VC6, and put MFC (and the PSDK) into VC++ Express. I don't think it is
anybody's interest to "entrap" beginners into C++/CLI.

--
David Wilkinson
Visual C++ MVP

[Hendrik Schober]

Re: learn C++ or C#

Pavel Minaev <int19h@gmail.c omwrote:

On Jul 19, 4:36 pm, "Giovanni Dicanio" <gdicanio@_NOSP AM_email_DOT_it >
wrote:
[...]

>Using tools like string classes, container classes and smart pointers makes
>C++ code robust and easy to write and manage.

>
Well, sort of. Until you accidentially invalidate an iterator by
modifying the container - U.B. Or mix signed and unsigned integer
types in an arithmetic expression and get weird results because of the
silent signed->unsigned conversion rule (and it is very easy to do so,
since a lot of standard library functions return unsigned integers -
e.g. size() of any STL container is unsigned). Or forget that
assignment operator and "copy" constructor for auto_ptr are actually
move and not copy. Or put an auto_ptr into a container (and why not,
if it lets you do so without any compaints...). Or try to make sense
of three paragraphs of ISO C++ standard describing overload resolution
for template functions in presence of partial specializations (the one
where synthetic types are involved). The problem is, you have to be a C
++ expert to write good C++ code, and, not any less important, to be
able to understand advanced C++ code written by others that's thrown
at you.

I've looked at this list and I agree with the unsigned vs. signed
issue, everything else I don't agree with. I can't see how you can
implement a dynamic array that doesn't invalidate iterators upon
insertion (might be my limited imagination, though).
I don't think I've used 'std::auto_ptr' in the last five years. If
I needed a smart pointer (which is rather rare if you use the above
mentioned tools) I needed (and used) a ref-counting off-the-shelf
one. And there's no function template partial specialization, so it
can't mess with the overloading rules.
I agree that C++ is a huge and complex beast to deal with, but I
also agree with Giovanni that a modern use of it leads to save,
robust, and easily maintainable code. Unfortunately I also have to
agree that too few programmers are using it that way.

I think it all boils down to the old observation that C's heritage
is both a bless and a curse for C++. That's valid for teaching it,
too. C++ was taught as a better C for far too long and that still
hasn't changed enough. To many studentsare taught a style that begs
for subtle bugs, alltough there are better ways to make use of the
language.
My personal opinion is that most programmers would benefit a lot
from reading Koenig/Moo's "Accelerate d C++" even though it's meant to
be for novices. I read it many years ago (because I teach C++) and
while I don't think it showed me anything I didn't know yet, it did
teach me that C++ has changed enough throughout the last 15 years to
make it possible to teach it to students in a way that makes them
programming the style Giovanni advertized from day one.
I have 15-20 lectures (90mins each) to teach C++ to students who had
one year of Java-only exposure and found that it's possible to go all
the way from "Hello, world!" to template meta-programming in that
time. I hammer a lot of rules of thumb into them and teach them a
style where C++ is a like big box of Lego bricks from which your can
safely build anything you need. I rarely ever have a semester where I
give an exercise where they have to write 'new', let alone 'delete',
but they see 'std::vector' in lesson two, along with 'std::string'
and IO. C++ is still more unsafe than other languages because it just
relies on programmers not to do stupid things, but given a modern
combination of compiler/RTL/std lib you get a lot of meaningful run-
time error messages in debug mode while still enjoying full speed in
release mode.

Don't get me wrong, C++ is a great language, and the time I've spent
writing in it was great. But from my experience, I would never let it
anywhere near domain logic except where it is spefically needed, when
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways.

But that's really hard to do if you don't do manual memory and the
like. Mostly this happens because programmers only use C++ as a
better C -- which is exactly what Giovanni said would lead to subtle
bugs.

I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.

IME the crashs reported from testing tend to happen in certain parts
of the code and correlate with the style used in there. I rarely saw
more than one crash per year in my code /while testing on my machine/
and went years without having one checked in.
And that's not really hard to do if you write code the way Giovanni
suggests.

Schobi

--
SpamTrap@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner

[Pavel Minaev]

Re: learn C++ or C#

On Jul 20, 3:07 pm, "Hendrik Schober" <SpamT...@gmx.d ewrote:

  I've looked at this list and I agree with the unsigned vs. signed
  issue, everything else I don't agree with. I can't see how you can
  implement a dynamic array that doesn't invalidate iterators upon
  insertion (might be my limited imagination, though).

Depends on the container, but that was not my point. In C#, if you use
an invalid enumerator, you will _consistently_ get an exception. In C+
+, unless you're using a debugging STL implementation (and even then
all checks are usually disabled in release mode by default), your
invalidate vector iterator will happily dereference, and you'll get a
segfault at best, and will silently read or write some random memory
value at worst - it's precisely how those "heap corruption" errors
appear.

  I don't think I've used 'std::auto_ptr' in the last five years. If
  I needed a smart pointer (which is rather rare if you use the above
  mentioned tools) I needed (and used) a ref-counting off-the-shelf
  one.

Ironically, a typical C++ refcounted smart pointer is often on average
slower than a good mark&sweep GC. Especially if you're using Boost/TR1
shared_ptr, which allocates the reference counter separately from the
object itself.

And there's no function template partial specialization, so it
 can't mess with the overloading rules.

My mistake, sorry. Just plain template specializations , not partial
ones.

By the way, partial function specialization will be in C++0x, so those
3 paragraphs might well become a few more :)

  I agree that C++ is a huge and complex beast to deal with, but I
  also agree with Giovanni that a modern use of it leads to save,
  robust, and easily maintainable code. Unfortunately I also have to
  agree that too few programmers are using it that way.

There's one more thing to it. "Modern use" of C++ really looks a lot
like C# or Java - you generally see MI only in context of abstract
base classes (read: interfaces), you see proliferation of pointers
over stack-allocated objects (again, because of interfaces), you don't
see many overly clever template metaprogramming abuses etc.

The question is then, if the "modern subset" of C++ closely matches
that of C#, but C# also doesn't have all the legacy cruft, then why
choose C++ over C# for a typical project?

(There are other valid reasons such as portability, but I'm
deliberately restricting this argument to languages only, not to
available implementations ).

  and IO. C++ is still more unsafe than other languages because it just
  relies on programmers not to do stupid things, but given a modern
  combination of compiler/RTL/std lib you get a lot of meaningful run-
  time error messages in debug mode while still enjoying full speed in
  release mode.

Until we get concepts in C++0x, essentially any C++ program that
heavily uses templates in general, and template metaprogramming in
particular (yes, that includes STL and Boost) is a rather masochistic
exercise when it comes to deciphering compiler error messages.

Don't get me wrong, C++ is a great language, and the time I've spent
writing in it was great. But from my experience, I would never let it
anywhere near domain logic except where it is spefically needed, when
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways.

>
  But that's really hard to do if you don't do manual memory and the
  like.

Not really. Perhaps I would have to clarify - my observations were in
a development environment where knowledge of the subtleties of C++ was
encouraged and widespread, and usage of STL in its entirety - not just
strings and containers, but also algorithms, binders etc, where
possible - was mandatory; and we also used shared_ptr/weak_ptr from
Boost, as well as a couple of our own Boost-style templates. We
certainly didn't use C++ as "better C" - far from it.

[Giovanni Dicanio]

Re: learn C++ or C#


"David Wilkinson" <no-reply@effisols. comha scritto nel messaggio
news:ejb5Iil6IH A.4112@TK2MSFTN GP05.phx.gbl...

What's the solution? I think MS has to fully face up to the fact that VC++
is for native code, get the IDE back to the level of
usability/responsiveness we had in VC6,

100% agree!

and put MFC (and the PSDK) into VC++ Express.

VC++ Express 2008 includes PSDK out-of-the-box.
Unfortunately, MFC is not there.

So, maybe the VC2008 Express users may use WTL for GUI development (I recall
there was an article on CodeProject about that).

However, a beginner who wants to write a GUI app for Windows can save lots
of time if he uses VC# Express with its RAD-style GUI designer.

Giovanni

[Larry Smith]

Re: learn C++ or C#

>I once met a very senior person in C++ circles (I won't mention his

>name) and I asked him for his opinion. He suggested that perhaps
>5% of all C++ programmers are competent.

>
5%? Maybe. It's certainly no more than about 10%.
>
The percentage doesn't change much for other languages, though, bad
programmers will write bad code in any language.

That's certainly true, but comparing a typical language to C++ is like
comparing a truck full of eggs to a tanker full of nitroglycerin. If your
driver's incompetent 95% of the time then you'll either end up with a lot of
broken eggs or a lot of dead bodies.

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

Re: learn C++ or C#

Daniel James wrote:

In article news:<u0RfIKc6I HA.2060@TK2MSFT NGP02.phx.gbl>, Larry Smith
wrote:

>I once met a very senior person in C++ circles (I won't mention his
>name) and I asked him for his opinion. He suggested that perhaps
>5% of all C++ programmers are competent.

>
5%? Maybe. It's certainly no more than about 10%.
>
The percentage doesn't change much for other languages, though, bad
programmers will write bad code in any language.

But in languages like C and C++ they can create bugs that are
both disastrous and very hard to find.

Arne

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

Re: learn C++ or C#

Jon Skeet [C# MVP] wrote:

Java 1.4 and C# 1.0 were very similar, but the languages have diverged
significantly since then. Almost all the new features in C# 2.0 and 3.0
either have no real equivalent in Java (e.g. iterator blocks, nullable
types) or have very significant differences (e.g. generics).

I don't agree for 2.0.

My list of .NET 2.0 & C# 2.0 new features and their "Java status":

FtpWebRequest - URLConnection has had support for FTP many years
Ping - missing
HttpListener - missing
GZipStream - GZIP*Stream has existed many years
partial classes - missing
DbProviderFacto ry - JDBC worked that way always
generics - Java got it in 1.5 (and it is not that different)
nullable types - Java has had wrapper objects forever
anonymous methods - Java has anonymous classes
static classes - missing
different accessability get & set - Java getters & setters obviously can

7 out of 11 seems to be in Java .

..NET 3.0/3.5 & C# 3.0 I will agree. Java does not have much of that
stuff and it does not seem as if Java will get it either in the future.

Arne

[Peter Duniho]

Re: learn C++ or C#

On Sun, 20 Jul 2008 16:49:43 -0700, Arne Vajhøj <arne@vajhoej.d kwrote:

Jon Skeet [C# MVP] wrote:

>Java 1.4 and C# 1.0 were very similar, but the languages have diverged
>significantl y since then. Almost all the new features in C# 2.0 and 3.0
>either have no real equivalent in Java (e.g. iterator blocks, nullable
>types) or have very significant differences (e.g. generics).

>
I don't agree for 2.0.
>
My list of .NET 2.0 & C# 2.0 new features and their "Java status":

It's not clear to me that your list is a complete enumeration of all .NET
2.0 and all C# 2.0 features. Heck, you didn't even include iterator
blocks, which was specifically mentioned by Jon.

And in your own list...

FtpWebRequest - URLConnection has had support for FTP many years
Ping - missing
HttpListener - missing
GZipStream - GZIP*Stream has existed many years
partial classes - missing
DbProviderFacto ry - JDBC worked that way always
generics - Java got it in 1.5 (and it is not that different)

I suppose that depends on your definition of "that different".
Personally, I'd say it's _very_ different. Java generics are just a
compile-time wrapper. I understand why they did it that way, but it
significantly limits their utility.

nullable types - Java has had wrapper objects forever

Not the same at all. Nullable<Tisn't just a "wrapper" for value types
(though I can see why one might view them that way). In particular, using
a wrapper in Java requires boxing the value.

Of course, since in Java you can't define your own non-nullable types, the
need for Nullable<Tin Java is obviously dramatically reduced. But the
wrapper types still aren't the same.

anonymous methods - Java has anonymous classes

And is missing delegates. Anonymous methods don't really make any sense
without delegates, so sure...maybe you don't see how anonymous methods
aren't the same as anonymous classes. But they aren't.

Now, if you want to argue that C# is missing anonymous classes, I don't
disagree with that. But having anonymous classes doesn't mean that Java
supports the same thing as anonymous methods.

static classes - missing

I don't understand this. Are you saying that C# didn't get to use
"static" when declaring a class until 2.0? That doesn't sound right to
me. I'm also not clear on what you mean by "missing" with respect to
Java, since you can effectively create a static class in Java just as
easily in C#.

I must be misunderstandin g what you mean by "static classes"...plea se
elaborate.

different accessability get & set - Java getters & setters obviously can

Java doesn't even have properties. The fact that Java's relatively
inferior work-around to lacking properties inherently allows different
accessibility for the getter and setter seems irrelevant to me.

7 out of 11 seems to be in Java .

I count different: 8 of 11 seem _not_ to be in Java (that's assuming
you're correct about "static classes"...sinc e I don't understand how
you're using that term, I might be wrong there :) ). Though, since your
list of new features for .NET 2.0 and C# isn't a complete enumeration
anyway, it's not like any count of that particular list is a useful
comparison anyway.

Pete

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

Re: learn C++ or C#

Peter Duniho wrote:

On Sun, 20 Jul 2008 16:49:43 -0700, Arne Vajhøj <arne@vajhoej.d kwrote:

>Jon Skeet [C# MVP] wrote:

>>Java 1.4 and C# 1.0 were very similar, but the languages have
>>diverged significantly since then. Almost all the new features in C#
>>2.0 and 3.0 either have no real equivalent in Java (e.g. iterator
>>blocks, nullable types) or have very significant differences (e.g.
>>generics).

>>
>I don't agree for 2.0.
>>
>My list of .NET 2.0 & C# 2.0 new features and their "Java status":

>
It's not clear to me that your list is a complete enumeration of all
.NET 2.0 and all C# 2.0 features. Heck, you didn't even include
iterator blocks, which was specifically mentioned by Jon.

It is a list I had from another context.

>generics - Java got it in 1.5 (and it is not that different)

>
I suppose that depends on your definition of "that different".
Personally, I'd say it's _very_ different. Java generics are just a
compile-time wrapper. I understand why they did it that way, but it
significantly limits their utility.
>

>nullable types - Java has had wrapper objects forever

>
Not the same at all. Nullable<Tisn't just a "wrapper" for value types
(though I can see why one might view them that way). In particular,
using a wrapper in Java requires boxing the value.
>
Of course, since in Java you can't define your own non-nullable types,
the need for Nullable<Tin Java is obviously dramatically reduced. But
the wrapper types still aren't the same.
>

>anonymous methods - Java has anonymous classes

>
And is missing delegates. Anonymous methods don't really make any sense
without delegates, so sure...maybe you don't see how anonymous methods
aren't the same as anonymous classes. But they aren't.
>
Now, if you want to argue that C# is missing anonymous classes, I don't
disagree with that. But having anonymous classes doesn't mean that Java
supports the same thing as anonymous methods.

>different accessability get & set - Java getters & setters obviously can

>
Java doesn't even have properties. The fact that Java's relatively
inferior work-around to lacking properties inherently allows different
accessibility for the getter and setter seems irrelevant to me.

You are missing the point.

The discussion is whether C#'s and Java's ways had split with C# 2.0
features.

The fact that Java does not have Nullable is not an indication of
such a split, because Java does not have any need for Nullable, because
in Java you use the wrapper classes. Different ways of achieving the
same goal.

Same applies to the rest.

These additions to C# made C# more similar to Java not less similar.

>static classes - missing

>
I don't understand this. Are you saying that C# didn't get to use
"static" when declaring a class until 2.0? That doesn't sound right to
me. I'm also not clear on what you mean by "missing" with respect to
Java, since you can effectively create a static class in Java just as
easily in C#.
>
I must be misunderstandin g what you mean by "static classes"...plea se
elaborate.

http://www.google.com/search?hl=en&q=C%23+static+class&btnG=Google+Search

>7 out of 11 seems to be in Java .

>
I count different: 8 of 11 seem _not_ to be in Java

Only if you count implementation.

But that is not so relevant for the discussion.

Though, since your
list of new features for .NET 2.0 and C# isn't a complete enumeration
anyway, it's not like any count of that particular list is a useful
comparison anyway.

It is a sample of the features.

As all samples it has some uncertainty, but claiming that a sample
is not useful shows a blatant lack of understanding of statistics.

Arne

[MC]

Re: learn C++ or C#

>>I once met a very senior person in C++ circles (I won't mention his

>>name) and I asked him for his opinion. He suggested that perhaps 5% of
>>all C++ programmers are competent.

>>
>5%? Maybe. It's certainly no more than about 10%.
>>
>The percentage doesn't change much for other languages, though, bad
>programmers will write bad code in any language.

>
But in languages like C and C++ they can create bugs that are
both disastrous and very hard to find.

Exactly. And that is what led us to get accustomed to personal computers
crashing, in the 1980s. Ten years earlier, in the mainframe era, with "less
powerful" languages, it was very hard for a program written in a high-level
language to crash the machine. Normally they terminated with recognizable
errors (e.g., divide by zero) or they simply misbehaved (produced the wrong
output). C# thankfully brings us back into that world. Program errors are
program errors, not computer crashes.

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

Re: learn C++ or C#

Daniel James wrote:

C++ can be used to write software for a huge range of systems -- not
only Windows but also Mac, linux and others (including mini and
mainframe computers, and embedded systems).

True.

But how many real life C++ program will actually run unchanged
(and without a zillion #ifdef's) on all those platforms ?

C++ can be used to write system-level code: operating systems, device
drivers, etc.. Although there are research projects and proof of concept
implementation that use C# for these things, current C# implementations
do not allow C# to be used for this kind of work with mainstream OSes --
you can't write even a Windows device driver in C#. If you want to do
driver work then choose C++ (or even C).

If one is into that type of stuff, then C/C++ is absolutely the rigth
way to go.

A good implementation plan is to write your back-end code -- the
business logic of your application -- in a fast portable language (such
as C++)

But why ? You will be able to write the same business logic cheaper
in Java, C# or Python.

You do not need any of the C/C++ specialties for that.

Arne

[Peter Duniho]

Re: learn C++ or C#

On Sun, 20 Jul 2008 18:55:20 -0700, Arne Vajhøj <arne@vajhoej.d kwrote:

[...]
You are missing the point.

That can only be true if you are as well.

The discussion is whether C#'s and Java's ways had split with C# 2.0
features.
>
The fact that Java does not have Nullable is not an indication of
such a split, because Java does not have any need for Nullable, because
in Java you use the wrapper classes. Different ways of achieving the
same goal.

So why did you include "nullable types" as an example of the "split" of
"C# and Java's ways"? If anything at all, that's an example of
convergence, not divergence.

Same applies to the rest.

Ditto.

These additions to C# made C# more similar to Java not less similar.

The addition of the Ping class make C# more similar to Java, even though
Java doesn't have that? Likewise all the other things that even you agree
Java doesn't have?

If you're trying to make a point, you're not being very clear about what
point it is you're trying to make. You keep writing things that are
mutually exclusive of each other.

>>static classes - missing

> I don't understand this. Are you saying that C# didn't get to use
>"static" when declaring a class until 2.0? That doesn't sound right to
>me. I'm also not clear on what you mean by "missing" with respect to
>Java, since you can effectively create a static class in Java just as
>easily in C#.
> I must be misunderstandin g what you mean by "static classes"...plea se
>elaborate.

>
http://www.google.com/search?hl=en&q...=Google+Search

Well, that's the definition I use. So that doesn't represent a change in
C# 2.0 at all. In either C# or Java you can write a static class (a class
with no instance members is by definition a static class). Just because
the keyword gained usage as a class declaration modifier in 2.0 doesn't
mean you couldn't static classes in 1.0.

In addition, you are again confused about what you're trying to
demonstrate. If Java's object wrappers for value types is in fact just
"different ways of achieving the same goal", then so too is simply
defining a class without any instance members just a "different way of
achieving the same goal".

Suffice to say, I find your assertions uncompelling.

[...]

> Though, since your
>list of new features for .NET 2.0 and C# isn't a complete enumeration
>anyway, it's not like any count of that particular list is a useful
>comparison anyway.

>
It is a sample of the features.

Then it's useless with respect to measuring the actual differences between
the languages.

As all samples it has some uncertainty, but claiming that a sample
is not useful shows a blatant lack of understanding of statistics.

Claiming that a sample _is_ useful without showing that it's a
statistically significant (large enough sample size) and statistically
correct (sample collected in a statistically random way) sample shows a
blatant lack of understanding of statistics.

Pete

[Jon Skeet [C# MVP]]

Re: learn C++ or C#

On Jul 21, 12:49 am, Arne Vajhøj <a...@vajhoej.d kwrote:

Java 1.4 and C# 1.0 were very similar, but the languages have diverged
significantly since then. Almost all the new features in C# 2.0 and 3.0
either have no real equivalent in Java (e.g. iterator blocks, nullable
types) or have very significant differences (e.g. generics).

>
I don't agree for 2.0.
>
My list of .NET 2.0 & C# 2.0 new features and their "Java status":

I'll restrict it to language features, as that's what I was talking
about.

partial classes - missing

Yup.

generics - Java got it in 1.5 (and it is not that different)

It's *massively* different. Hugely, vastly different. IMO, of course,
but type erasure is fundamental difference IMO.

nullable types - Java has had wrapper objects forever

Not the same thing. While I don't like to micro-optimise too often,
the fact that Nullable<Tis still a value type in C# 2 is a big deal.
Likewise the fact that you can deal with *any* nullable type
generically , instead of having to know the wrapper type in advance.

anonymous methods - Java has anonymous classes

Unwieldy enough to be a real pain, and read-only access to local
variables. As Peter says, the lack of delegates is significant here.

static classes - missing

Yup.

different accessability get & set - Java getters & setters obviously can

Yup.

In addition:
o Iterator blocks
o Other improvements to delegates (irrelevant to Java without
delegates to start with)

7 out of 11 seems to be in Java .

In my count, only "different accessibility for properties" is really
there for Java.

Jon