C# vs. C++

[Arne Vajhøj]

From my experience (see above) I think this, while it
seems "obviously right", is wrong. My students, having
been taught Java first, have a lot of trouble learning
to pay attention to details like memory, passing strings
per (const) reference etc., because they aren't used to
it. Some told me that only after my course they started
to understand many things in Java.
C++ programmers, OTOH, have no problem picking up Java
or C#.

I agree that by learning C++ first then Java and C# programmers
get a much better understanding of what is really happening and
that Java and C# programmers learning C++ often will have a hard
time.

But there is a non technical aspect as well. The give up
ratio for C++ is much higher than for the other languages.
If you teach C++ to 50 students, then you may get 10 great
programmers and 40 that swear never to try and program again.

Arne

 

[Arne Vajhøj]

Sleight of hand. I worked for a few years in the telecommunications
industry. C and C++ happen to be entrenched there because at the time
that was the dominant languages. As these pieces get re-written,
rest-assured they won't be re-written in these languages because there's
nothing to gain using these technologies in telecommunications. I know,
I've been there.

Applications rarely get rewritten. I would expect most of the existing
C and C++ apps to continue running for a decade or two more. Just
think of how many 30 year old Cobol and PL/I code that are still around.

New apps will likely be written in something else (Java or .NET) unless
there are special reasons not to (hardware interfaces or real time
requirements or requirement for very low memory footprint).

Arne

 

[Arne Vajhøj]

Why is it more powerful and more flexible? I thought you could write
'unsafe' code in C#. Doesn't that make it as powerful and as flexible.
Or perhaps unsafe code was removed from C#, if so then I stand corrected.

It is still there.

But the trouble interacting between unsafe and safe code
makes it not very attractive in my eyes. If I had a need
for that type of code, then I would do it in C++.

Arne

 

[Andre Kaufmann]

Rudy Velthuis wrote:
[...]
It could. And I am sure it will.

But new mainstream OS's are rather rare. I think the newest
must be Linux from 1991.

I would call Linux from 1991 experimental too. At least I remember it to
be a huge experiment to get it up and started ;-).

[...]
Arne

 

[Cholo Lennon]

C# also has abstract classes and even though abstract classes can
be used instead of interfaces, then interfaces especially when
combined with the only inherit from one class but implement
multiple interfaces rules really guide users towards good
OOP style.

It's a point of view...

TR1 is fine, but strictly speaking it is not C++ yet (it may
be in 2009 rumors say).

Well, some compilers are distributing partial tr1 implementations and function
is included. BTW boost::function (in which std::tr1::function is based) has many
years and is widely used in modern C++ code / production code.


Regards

 

[Hendrik Schober]

I agree that by learning C++ first then Java and C# programmers
get a much better understanding of what is really happening and
that Java and C# programmers learning C++ often will have a hard
time.

But there is a non technical aspect as well. The give up
ratio for C++ is much higher than for the other languages.
If you teach C++ to 50 students, then you may get 10 great
programmers and 40 that swear never to try and program again.

Not IME.

Arne

Schobi

 

[Hendrik Schober]

[...]
That is a good point. Object-oriented programming wasn't mature when C++ came into use. There is a lot of bad C++ code in the
world, and C++ makes it easy to write bad code and create programs that crash.

I think C will outlive C++. C is going to continue to be a good language for small routines where performance is paramount. For
such things, I find myself writing "C-barely-plus-plus," which is C with slight use of the C++ extensions. [...]

IMO these to paragraphs contradict each other. C makes it a lot
easier to write bad, crashing code, than C++ does.

Since C++ support practically all of C then ...

...if C++ wouldn't do so much to make it easy to write
better, safer code, my above statement wouldn't make
sense. Yes. Your point?

Arne

Schobi

 

[cj]

Geesh, I sure got a lot of posts on that one. I'm not sure where I'm
headed but I appreciate the opinions.

 

[Adhal]

Geesh, I sure got a lot of posts on that one. I'm not sure where I'm
headed but I appreciate the opinions.

lol Is become a C++ forum. Nice thread.

Learn a bit of C++ first, even just the basics you will appreciated C# more. Don't go into depth
just basics.

I knew a bit of C and C++ and currently learning C#. I love C# because it reminds me of C and has
encouraged me to learn C++. Once I am more confident in C# I will begin to dig in C++.

Also note all games are written in C & C++. Well most mainstream commercial games. C++ is not going
to die out within our lifetime.

Those who say is dying are talking rubbish and hype. C++ programmers will die out long before C++.
That is the most likely outcome, and watch salaries soar.

 

[Arne Vajhøj]

[...]
That is a good point. Object-oriented programming wasn't mature
when C++ came into use. There is a lot of bad C++ code in the
world, and C++ makes it easy to write bad code and create programs
that crash.

I think C will outlive C++. C is going to continue to be a good
language for small routines where performance is paramount. For
such things, I find myself writing "C-barely-plus-plus," which is C
with slight use of the C++ extensions. [...]

IMO these to paragraphs contradict each other. C makes it a lot
easier to write bad, crashing code, than C++ does.

Since C++ support practically all of C then ...

...if C++ wouldn't do so much to make it easy to write
better, safer code, my above statement wouldn't make
sense. Yes. Your point?

Should be obvious.

Arne

 

[Arne Vajhøj]

It's a point of view...


Well, some compilers are distributing partial tr1 implementations and function
is included. BTW boost::function (in which std::tr1::function is based) has many
years and is widely used in modern C++ code / production code.

boost != C++

But on the other side:
- very few are using only ANSI features
- boost is widely used
- the C++ standardization process is let us call it thorough
so maybe it is a more fair comparison to include boost in C++
functionality.

Arne

 

[Arne Vajhøj]

I'd call that a positive result! Certainly better than getting 50
mediocre programmers.

Seen from a puristic point of view I will agree. But there
is this aspect of the world called money - we need millions
of programmers to code business apps.

Arne

 

[Alvin Bruney [ASP.NET MVP]]

Don't confuse flexibility with lack of safety -- you can have the one

without the other.

How is this confused? My point was C# is not less flexible because it allows
pointer tricks, something that C++ claims as an advantage, safety or lack of
it has nothing to do with the argument. At the end of the day, you have the
best of both worlds in C#.

The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.

And what is that good for? I wouldn't go searching for obscure features to
compare against C#. What I would do is compare common code paths and
implementation. Like it or not, C++ is a dying sport. Holding on to
obscurities will not inject life into it.

more strictly, to provide a plugin replacement for Java

That's new. By the same token C++ was what to C?

It's time to let go of C++. Really, it is. It's done for.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99

 

[Alvin Bruney [ASP.NET MVP]]

What's replacing them for the real-time control portions of the code?
Real time control where? If you are talking at the switch level, that's C
code. Period. I'm not aware of any of the major telecom players who would
touch that code because it is business critical. You could interpret that as
C is superior. I'll interpret it as don't mess with it because it ain't
broke.

Anything north of the switch to include the billing platforms, call routing
on up to client reporting and statistics is not C and not C++.

I once wrote a C# proof of concept for a company just to show that C# could
outperform C for billing and summarization. It worked, hands down, because
C# has a better memory allocation model for memory intensive applications,
which billing and summarization is. However, nobody wanted me to implement
the concept in the real world because the existing application was 'mission
critical'. go figure. C at the real time portion of the code is not there
because it brings any major advantage over what we have today.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99

 

[Alvin Bruney [ASP.NET MVP]]

I agree 100%. I should have said earlier "if these pieces get re-written..."

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99

 

[Arne Vajhøj]

Real time control where? If you are talking at the switch level, that's
C code. Period. I'm not aware of any of the major telecom players who
would touch that code because it is business critical. You could
interpret that as C is superior. I'll interpret it as don't mess with it
because it ain't broke.

Or the real time requirements and/or requirements for low
memory foot print does not lend itself to a C# solution.

[I don't know but I assume that a switch has relative
little memory]

Arne

 

[RFOG]

Then, Alvin, next Windows will be done in C#?

Don't confuse flexibility with lack of safety -- you can have the one
without the other.

How is this confused? My point was C# is not less flexible because it
allows pointer tricks, something that C++ claims as an advantage, safety
or lack of it has nothing to do with the argument. At the end of the day,
you have the best of both worlds in C#.

The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.

And what is that good for? I wouldn't go searching for obscure features to
compare against C#. What I would do is compare common code paths and
implementation. Like it or not, C++ is a dying sport. Holding on to
obscurities will not inject life into it.

more strictly, to provide a plugin replacement for Java

That's new. By the same token C++ was what to C?

It's time to let go of C++. Really, it is. It's done for.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------

Don't confuse flexibility with lack of safety -- you can have the one
without the other.

Why is C++ more powerful than C#? Because you can do more things with
it, in more ways. C# is designed to support the "Object Oriented"
paradigm (or, more strictly, to provide a plugin replacement for Java
-- which is an almost religiously 'pure' OO language) but C++ is a
multi-paradigm language -- it can "do OOP", but it can be used to
implement other designs as well.

The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.

Cheers,
Daniel.

--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
Una palabra mal colocada estropea el más bello pensamiento.
-- Francois Marie Arouet.

 

[Hendrik Schober]

[...]

The single most glaringly obvious example of what I mean is that you
can't do template metaprogramming in C#, but there are others.

And what is that good for? [...]

It shifts tasks from the run-time to the compile-time. IMO
the biggest advantage of this is that you catch more errors
at compile-time. OTOH, this allows C++ to rival FORTRAN's
speed for some applications, which for some people is far
more important.
I wouldn't call these obscure features.

Schobi

 

[David Wilkinson]

It's time to let go of C++. Really, it is. It's done for.

Says who?

C++/CLI as a first class .NET language does indeed appear doomed. Maybe using
C++ for .NET was a bad concept from the beginning, or maybe it was done in by
the flawed initial version of MC++. But, anyway, it seems dead.

C++/CLI is great for inter-op, but that is a limited market compared to all the
things that C# can do in .NET.

But native C++ lives on, both as a cross platform language, and in many
MFC/Win32 applications that are never going to switch to .NET. The Visual C++
team is strongly committed to improve the native coding experience in the next
version of Visual Studio, after many years of neglect.

It is a pity that MFC is a bloated and not very elegant framework, but it works.
It can still be used to create applications that would be difficult to do in C#.

And if you do not like MFC, there are WTL, wxwidgets, QT ... A lot of C++ code
is non-GUI anyway.

C++ is not dead yet. And C# is not the perfect language either. Too much
influenced by Java, IMHO.

 

[Andre Kaufmann]

.. and your point is misplaced because it is largely not the ability to
perform "pointer tricks" that makes C++ more flexible or more powerful.

Yes, being able to manipulate machine addresses through pointers may
make C++ a suitable choice for very low level code (firmware, drivers,
etc.)

-- which C# is not

Hm, why ? Singularity / Cosmos are operating systems in C#. The
MicroFramework targets embedded devices.

-- but on most modern architectures (with
hardware memory management and address remapping) C++'s addresses don't
correspond to meaningful physical memory addresses anyway.

No, pointer manipulation is not what we're discussing, here.

O.k. pointer manipulation is the main task of C ;-).

[...]
There's nothing obscure about TMP. It's what makes the C++ standard

Hm, which C++ standard library is using meta templates ? IIRC Tr1 will
use them, boost library uses them but the STL ?

library so hugely powerful, it's what makes some of the amazingly useful

Which powerful standard library in C++ can I use for file operations ?

libraries in, for example, Boost possible.

Boost is a good, cool library - sure. But these libraries get somewhat
bloated, because of all the template stuff and compilation slows down
more and more.

And for example I dare to say that boost::function has a higher
overhead, than C# delegates.

Modern C++ code is built on
templates and it makes the language hugely more powerful than a

I thought it to be so too. I have implemented discriminated unions, used
type lists as they are in Loki for example and all the nice stuff.
What I got was unreadable, hard to debug and bloated code which needed a
very long time to compile.

The one compiler emitted code with a size of 3MB, the other one compiled
the same sources to 6MB.

After I had replaced all the TMP stuff by generated code the code size
could be reduced to 1MB.

classical OOP language like C# or Java could ever hope to be. Even if a
C++ programmer never writes a single template in his whole life he has
all the power of those libraries to draw upon.

Could you give me an example (part of a library), which is more powerful.

C++ is based on C, but is not a simple replacement. The syntax of C++ is
almost a proper superset of that of C (i.e. most, but not all C source
will compile correctly if fed through a C++ compiler) with new semantics
and new functionality that represent an evolutionary increase in
flexibility and power.

But C++ inherited the worst from C - macros.

C# is based on Java. It has a slightly different syntax and a different
set of runtime APIs, but it is semantically very similar -- a little
better, because some of the mistakes of Java were not repeated, but
largely similar. Where is the evolutionary advance here? Nowhere.

- LINQ
- Delegates
- Library, which isn't bound to a single language
- Lambda expressions
- Implicit typed variables
- and many more

C++ will get some of these too, but then the argument that C++ hasn't
invented these could be used too.

You really have no idea.

Hm, I once was a die hard C++ developer and argued the same way. But
today I'm not that sure about C++ and it's future.
I would prefer >every time< a native C# or would prefer the 'D'
language, if it would be better supported by most of the commercial
developer tools and could (directly) compile (old) C++ code.

Have you used another language than C++ too, to make a good comparison ?

I don't want to start a language war - better said continue one. But I
too think the evolution of C++ is currently too slow and heading in the
wrong direction, since modules in C++ are still delayed. If I compare
what abstraction level I can reach for example with F# and how I'm still
able to use my C# code easily, I don't think that C++ is still the

only< way to go.

Cheers,
Daniel.

Cheers,
Andre