learn C++ or C#

[Arne Vajhøj]

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.

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.


Not the same at all. Nullable<T> isn'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,


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.

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.

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 misunderstanding what you mean by "static classes"...please
elaborate.
http://www.google.com/search?hl=en&q=C#+static+class&btnG=Google+Search


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

 

[Arne Vajhøj]

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

 

[Jon Skeet [C# MVP]]

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<T> is 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

 

[Jon Skeet [C# MVP]]

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.

No, you couldn't. A static class isn't just "a clas with no instance
members". On the declaration side, when a class is made static the
compiler will *prevent* you from adding instance members. It also
means you don't have any constructors at all, which is impossible in
C# 1 - you get a default constructor if you don't specify any
constructors.

On the calling side, a class declared as static can't accidentally be
used like a "normal" class. You can't declare a variable of that type
(including parameters) or use it as a generic type parameter, for
example.

I'm not claiming these are massive differences, but they're things
which couldn't be achieved in C# 1. They let the compiler help you
find potential problems before they occur - as well as making
intentions clearer to other developers, of course.

Jon

 

[jmDesktop]

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.

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

Just a definition question. What does "domain logic" mean? Thanks.

 

[Jon Skeet [C# MVP]]

Indeed, you need the command line option -langversion:linq but to
quote the documentation:

<quote>
This enables the C# 3.0 support. Only a few features of C# 3.0 have
been implemented in the Mono C# compiler, so not everything is
available.
</quote>

Update to this - I've been chatting with Miguel de Icaza recently
(about something else) and he mentioned that the C# 3.0 support is now
actually completed. I'm not sure how much of it has been released yet,
but when Mono 2.0 comes out it should be fully C# 3.0 compliant.

Jon

 

[Pavel Minaev]

Just a definition question.  What does "domain logic" mean?  Thanks.

Essentially a synonym for "business logic". As usual, see Wikipedia
for details:

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

 

[Ben Voigt [C++ MVP]]

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 misunderstanding what you mean by "static classes"...please
elaborate.

Java and C# use the term "static class" in totally different ways. In C#, a
nested class definition provides privileged access to private members of the
parent when properly addressed using a parent reference, and to generic
argument of the parent, but not an instance of the parent. In Java, a
nested class definition creates an "inner class" which is bound to an
instance of the parent, sort of like the closure that C# uses for anonymous
methods. In Java, "static class" is used to create a nested class that
isn't also an "inner class".

 

[Ben Voigt [C++ MVP]]

But in languages like C and C++ they can create bugs that are

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.

This has absolutely zilch to do with language and everything to do with the
monolithic vs micro-kernel war.

 

[Ben Voigt [C++ MVP]]

and IO. C++ is still more unsafe than other languages because it just

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.

That's what comments are for. We've had the capability to implement
compile-time asserts for quite some time, and the compile error will bring
you directly to the assert and the associated explanatory comment. Concepts
will be nicer of course, but it's not true to say you can't work with
templates usefully.

 

[Ben Voigt [C++ MVP]]

[David Wilkinson]

Fortunately most of my consulting work is cross-platform non-GUI
C++, si I do not need to worry about this. The code is developed in
Visual Studio, but runs as a console application in various
linux/Unix systems, as well as Windows. My client also wraps it in
C++/CLI for Windows GUI with C#, but I am not responsible for that.

Do you know if it is possible to throw native C++ exceptions from the
C++ layer, and directly catch them at the C++/CLI or C# layer?

For synchronous exceptions, no. If the C++ code is compiled with
asynchronous exceptions, then they map onto Win32 structured exceptions,
just like .NET exceptions, and they can be caught by .NET exception handlers
(although they will all appear as a generic 'C++ native exception' with no
more information available).

 

[JF]

C# would not be a serious choice for the professional programmer

if the tool support was as good for C++, and it's sad that C++'s
acceptance
is being hampered just because the inferior language has better tools.

Presumably you've seen what most "C++" programmers pass off for code.
Therefore, while you may in fact be an excellent C++ programmer yourself (a
very rare breed), in reality most companies are bleeding huge $ from the
mess their so-called C++ programmers are producing. The bloodpath for most
other languages is also messy but far less severe. Whether it's
intrinsically superior to C# or not is therefore meaningeless. Outside the
halls of academia, C++ is (usually) a failure because most practitioners
can't handle it as well as a simpler and more forgiving language like C#
(which is hardly a second-rate language in its own right).

 

[Pavel Minaev]

So, yes, I think native code is the way to go for C++ ... and I'd choose
Java rather than C# for the sandboxed environments because it has greater
market penetration. To me, C# is a language that should never have been.
The case for it was only ever a business case (the licensing difficulties
with Sun over Java) not a technical one.

Personally, looking at how slow Java develops, and how much mess they
accumulate due to need to stay backwards, and general resistance to
change (see Java generics for an example), I'm glad that we have C#
for purely technical reasons.

 

[Ben Voigt [C++ MVP]]

Presumably you've seen what most "C++" programmers pass off for code.
Therefore, while you may in fact be an excellent C++ programmer
yourself (a very rare breed), in reality most companies are bleeding
huge $ from the mess their so-called C++ programmers are producing.
The bloodpath for most other languages is also messy but far less
severe. Whether it's intrinsically superior to C# or not is therefore
meaningeless. Outside the halls of academia, C++ is (usually) a
failure because most practitioners can't handle it as well as a
simpler and more forgiving language like C# (which is hardly a
second-rate language in its own right).

But most of the C# coders have only a fraction of the skill set (and
understanding of the underlying system) of even the not-so-good C++
developers. So yes, the average mistake made by the C++ dev is more
expensive to fix... but that doesn't mean that the C# coders won't make the
same mistake or that it won't be just as hard to fix when they do (though it
may be "less expensive" in dollars because C# man-hours cost less).

 

[Giovanni Dicanio]

[Daniel James]

So, yes, I think native code is the way to go for C++
Agree.

... and I'd choose
Java rather than C# for the sandboxed environments because it has greater
market penetration. To me, C# is a language that should never have been.
The case for it was only ever a business case (the licensing difficulties
with Sun over Java) not a technical one.

I don't know about C# vs. Java market penetration.
However, I think that C# 3.0 is much better than Java. I'm glad that
Microsoft designed such a language (and framework).

Cheers,
Giovanni

 

[Larry Smith]

But most of the C# coders have only a fraction of the skill set (and

understanding of the underlying system) of even the not-so-good C++
developers.

Their understanding of the system is definitely superior but their
programming skills probably aren't much better. Most would likely write very
poor C# code as well, only now they have a safety net.

So yes, the average mistake made by the C++ dev is more expensive to
fix... but that doesn't mean that the C# coders won't make the same
mistake or that it won't be just as hard to fix when they do (though it
may be "less expensive" in dollars because C# man-hours cost less).

We definitely part company here. Pretty much every C++ program I've ever
seen is infested with serious design problems and outright bugs (latent or
otherwise). While I don't doubt that most C# programs have many problems as
well, it's not nearly on the same order of magnitude. The complexity of C++
coupled with the number of ways to shoot yourself in the foot (or rather
"blow your leg off" as Stroustrup once put it) makes it the 3rd rail of
programming languages. With C# you'll likely cry, with C++ you're gonna fry.

 

[Andre Kaufmann]

JF wrote:
[...]
But most of the C# coders have only a fraction of the skill set (and
understanding of the underlying system) of even the not-so-good C++

The problem is that you don't need the same skill set in C# (or other
languages) to solve a single problem and therefore even an experienced
developer will make less mistakes.

Multi-threading, GUI development is much easier in most of the other
languages compared to the efforts you have to take in C++, because they
support it out of the box. Fortunately C++ has Boost.

I've been a long time a die hard C++ programmer, but after having used
other languages like C#, D, Delphi or extending my C++ applications with
Python, Lua I know ask myself why all the stuff must be that complex in C++.

The only programming paradigm I miss in the other languages is RAII.
That's IMHO still a big plus of C++.

developers. So yes, the average mistake made by the C++ dev is more
expensive to fix... but that doesn't mean that the C# coders won't make the
same mistake or that it won't be just as hard to fix when they do (though it
may be "less expensive" in dollars because C# man-hours cost less).

A simple example:

How do I ensure in C++ that I have successfully overridden a base class
virtual function and that the compiler throws an error if the base class
implementation has changed ?

Andre

 

[Larry Smith]

Multi-threading, GUI development is much easier in most of the other

languages compared to the efforts you have to take in C++, because they
support it out of the box. Fortunately C++ has Boost.

To be fair, this has nothing to do with C++ as a language (which has no
support for multi-threading or GUI whatsoever). You have to separate the
tools from the language itself.

The only programming paradigm I miss in the other languages is RAII.
That's IMHO still a big plus of C++.

RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
..NET advocates will point out that the GC takes care of cleaning most
resources so the programmer has to do nothing at all. IMO the C++ paradigm
is still a better design but the reasons run too deep to get into here.

A simple example:

How do I ensure in C++ that I have successfully overridden a base class
virtual function and that the compiler throws an error if the base class
implementation has changed ?

C++ has many warts, many a legacy of C itself. From cast issues (very
dangerous) to forgetting to handle newly added class members in your
existing copy constructors and copy assignment operators. Templates are also
an incredible source of difficulty and potential errors (very difficult to
understand, read, and get right beyond the basics - some things will be
improving in C++0x but it's really too late). The use of #includes and
headers in general (from C) is also a hornets nest of serious problems. Not
to mention the usual issues of pointer handling, the cryptic nature of the
syntax itself (from C style arrays to function pointers to many types of
arcane C++ constructs like binders, adapters, etc. - did I mention
templates?). The dizzying array of rules and trap doors in general is very
difficult to master.

I also have some serious pet peeves. Why didn't they permit local classes to
be passed as template arguments. I once asked Stroustrup about this at a
conference but I wasn't satisfied with his terse response. The fact is that
many templates are useful for small local tasks. Why should I use the
"for_each" template for instance (among many others) if the tiny function
object I want to pass has to be declared outside the function itself (where
I'm using "for_each"). It would be so much cleaner to just declare the
function object locally. C# allows me to use anonymous methods which is so
much cleaner. The issues surrounding C++ go on and on.

Don't get me wrong, C++ is still a very powerful and flexible language with
incredible versatility (and very elegant design constructs in spite of all
the problems). The trade-off is that it's very difficult to master and
therefore prone to many serious problems. Even very experienced developers
have to continuously bend their minds out of shape and remain on guard years
after learning the language. This is not the hallmark of a successful
language in spite of C++'s "stellar" reputation and the millions who
continue struggling with it.

 

[Giovanni Dicanio]

[Larry Smith]

RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
.NET advocates will point out that the GC takes care of cleaning most
resources so the programmer has to do nothing at all.

The GC is fine for memory resources - it runs a garbage collection process
when under memory pressure.
But, what about non-memory resources (like sockets, textures, files, etc.) ?
I think that GC is designed for memory resources only, and has very little
clue about non-memory resources.

Instead, if you use RAII and a smart pointer (like shared_ptr, or some
intrusive reference count smart pointer) to manage non-memory resources,
they will be released as soon as the ref count becomes 0, making a very
efficient use of precious resources.

Yes, C# is a very well designed language, which incorporates lots of lessons
learned from C++, Java and Visual Basic.
But C# has not discovered destructors yet

Giovanni

 

[Larry Smith]

The GC is fine for memory resources - it runs a garbage collection process

when under memory pressure.
But, what about non-memory resources (like sockets, textures, files, etc.)
?
I think that GC is designed for memory resources only, and has very little
clue about non-memory resources.

Yes, that's what "IDisposable" is for as previously mentioned. The "using"
statement is just a compiler-generated wrapper around it, putting your code
in a "try/finally block behind the scenes and calling
"IDisposable.Dispose()" for you. RAII is clearly much better than this.

Instead, if you use RAII and a smart pointer (like shared_ptr, or some
intrusive reference count smart pointer) to manage non-memory resources,
they will be released as soon as the ref count becomes 0, making a very
efficient use of precious resources.

Yes, C# is a very well designed language, which incorporates lots of
lessons learned from C++, Java and Visual Basic.
But C# has not discovered destructors yet

Actually it has destructors but they're not the same as C++ destructors
(they're just compiler-generated wrappers for "Object.Finalize()"). I
already agree that object creation/destruction in C++ is cleaner and more
natural IMO. This hardly makes up for the many problems in C++ however. Like
many others, I have a love/hate relationship with it but objectively
speaking (IMO anyway), it's still a failure for the reasons I mentioned
previously.