C# vs C++

re: C# vs C++

Nicholas Paldino [.NET/C# MVP] — Wed, 26 Jan 2005 17:20:00 GMT

In the "Tools" section, I think you meant to say:

Reflection is a great feature, and enables doing a ton of things that are pretty hard to do in the C++ world

Note the C++, not C#.

The outcome is not surprizing. You give some interesting points for what C++ offers, but with cost of memory, and Longhorn on the horizon, most of those points will be nullified, I'm assuming (at least on a Windows platform).

re: C# vs C++

Wed, 26 Jan 2005 17:29:00 GMT

C or C++ are NOT application languages People seem to forget that.

re: C# vs C++

Wed, 26 Jan 2005 17:30:00 GMT

Cross platform is a win, unless you are in the embedded market. Put aside the ego and use the right tools for the job.

re: C# vs C++

David Brabant — Wed, 26 Jan 2005 17:49:00 GMT

> What did I miss?

Templates, template metaprogramming, STL, Boost.

re: C# vs C++

DrPizza — Wed, 26 Jan 2005 17:52:00 GMT

"In the C++ world, some functions return HRESULT, some return a bool, some return another set of status code, and some return a number and use an out-of-range value as an error indicator. Oh, and some are void. You not only have to write the correct code there, you have to successfully convert back and forth between the various kinds of error handling. "

Right, because these things can't happen in C#....

Yeah, uh huh.

re: C# vs C++

David Brownell — Wed, 26 Jan 2005 17:53:00 GMT

As an avid C++ user, I would say your points are very fair and paint an accurate picture of the problems of C++. However, I would place a caveat next to your comments on Automatic memory management. While possible in C++, resorting to the manual deletion of memory via pointers is not something that is recommended. Smart pointers, auto_ptrs, and move pointers mitigate all of the risk of manual memory management. I haven’t manually called delete in years (except when I am working with legacy C-based libraries).

Here are a couple of advantages of C++ that I didn’t see mentioned in your article.

1) Deterministic Destructors (DD). Having explicit knowledge of when a destructor is called leverages Resource Acquisition Is Initialization (RAII) techniques. This is just a fancy was of saying, “An object’s destructor is called when the object goes out of scope, and this destruction can be used to free resources, close handles, perform cleanup, etc.” C# has the using statement, but this is more intrusive that the syntax you get with C++.

Also, without DD, it becomes difficult to enforce a function’s strong guarantee (an application’s state is either modified upon successful completion of the function or unchanged upon unsuccessful completion of the function or in the presence of exceptions. Think of it as a transactional function. More info: http://www.boost.org/more/generic_exception_safety.html">http://www.boost.org/more/generic_exception_safety.html). To achieve this in any language that doesn’t have DD means wrapping each function in a try/catch block and performing undo action in the catch before rethrowing the exception. In C++, objects can be created on the stack with the undo actions in their destructors. Once the function’s processing is successful, the object’s destruction actions are dismissed. Function adapters and lambda expressions make these undo functions especially easy to create (http://www.boost.org).

2) Policy based design. Using templates, it is possible to achieve compile time polymorphism. This design relies on a type’s capabilities rather than its abstract base class. This creates faster and, IMO, cleaner code.

3) Template Metaprogramming. It is possible to create type containers that behave differently based on the contained type. For example, a container with an integer may provide a calculate method with the same container with a string may not provide a calculate method. In this contrived example it doesn’t sound like a good idea, but it allows remarkable syntactical consistency for container types. For an example, check out ThreadSafeObject (http://www.nwcpp.org/Meetings/2003/09.html), a type that ensures thread safety for contained objects using a clean syntax.

re: C# vs C++

Frisky — Wed, 26 Jan 2005 19:55:00 GMT

I have been a C++ programmer for many years prior to C#. In short, C# is a refined C++.

However, I always worry about memory management. I want deterministic destructors. (Yeah, I use IDisposable a lot, but sometimes, I know better when I want to free something.)

I used multiple inheritence a lot. (Very similar to intefaces, but I want some default behaviour that I don't have to code or at least requires very little code to hook up an existing implementation.)

I really miss const functions, mutables, and volatiles. Sure, I can write stuff that does the same thing, but the compiler does not catch all the stuff I want it to catch.

And I cannot wait for template classes, err, generics.

I can't wait for the refactoring tools and code snippet/template libraries I hear about in the new Visual Studio.

I love the .Net libraries. I love the VS RAD environment. (Minus the refactoring and stuff above.)

But most of all, I love that I can write something really cool, high tech, and blow your socks off in about 100 lines of code and 20 minutes. That is what its all about!

Frisky

re: C# vs C++

Nick Wienholt — Wed, 26 Jan 2005 20:07:00 GMT

On the C++ side:
* Generally better exposure of CLR features, but the gap is small with C# 2.0 vs C++/CLI.
* A better optimizing profiler.
* And the big one - PInvoke free interop

re: C# vs C++

Bas Westerbaan — Wed, 26 Jan 2005 20:16:00 GMT

Although a .net application uses way more memory it is very smart in using it. I can allocate a 1 000 000 000 byte array without actually needing 1 Gig memory it seems as long as I don't use all of it with C#. Also C#'s GC puts objects that are of the same generation and thus most likely to use eachother close to eachother which makes it a lot faster (CPU loads memory not directly but via the CPU cache which gets a block of a certain size, if that block contains all the objects required you are lucky). Although C++ programmers tend to say the GC is slow is very wrong. The malloc function works a bit like the GC (seeking free space), but it doesn't clean up except when in trouble and then malloc is really slow (the GC of .net outperforms malloc by far).
And lots of other stuff like efficient optimalization from IL to native images optimised for the cpu currently used by the ahead in time compiler. etc..

re: C# vs C++

Bill Clark — Wed, 26 Jan 2005 20:18:00 GMT

What David Brownell said. I would also want to take issue with your statement "In C#, I usually don't have to worry about the memory aspects." I find that in a long-running app (which is what I am working on now), memory management is much harder in C# than it is in C++. I have to worry exactly as much in both environments about who owns every new'ed object, but this is significantly more difficult in C#, where deterministic cleanup has to be the responsibility of clients and can't be encapsulated in the resource owner. Non-deterministic cleanup is taken care of by the GC, but in a long-running app that doesn't help me - I need to know that when I'm done with the thing, it's gone, *now*. Yes, it's possible to handle these problems through coding standards and thorough reviews - but this is far less effective than the guarantees you get from DD.
Well, the GC saves me from having to worry about cyclic references. To my mind, it solves a not-very-difficult problem and replaces it with a number of very hard and insidious ones.

Who needs C anyway?

MSDN Student Flash — Thu, 27 Jan 2005 04:19:00 GMT

re: C# vs C++

Darren Oakey — Thu, 27 Jan 2005 01:22:00 GMT

Everyone's mentioned template metaprogramming, but I'll throw in my agreement.

While I'm wholeheartedly convinced that C++ is now a dead language, I really miss two things - templates and const.

With const, you could write a very safe program, which is nearly impossible to do in C#.

The power of templates was incredible. I'm a firm devotee of DSL's, and templates really did allow you to basically build your own language - especially combined with typedef and (shock horror) the occasional #define.

Generics are very good, and essential, but they just reduce the amount of code you write - they don't take any steps towards your own domain specific language - and that's a huge loss IMO.

re: C# vs C++

Alex — Thu, 27 Jan 2005 01:49:00 GMT

C++ is not dead. The Windows desktop/server world is not all there is, folks.

That said, C# is the language to program in if you're on a Windows desktop. The only things I wish it had (and are already mentioned):

templates -- typesafe containers are very, very good things. I mean, what's with this casting crap whenever I want to a stack in C#.

deterministic destructors -- RAII is a very good thing.

re: C# vs C++

SBC — Thu, 27 Jan 2005 01:51:00 GMT

My preference is for C#, after having worked on C++ for numerous years ( http://weblogs.asp.net/sbchatterjee/archive/2005/01/26/361136.aspx ). Now that C# has evolved with generics - it would be nice to see comparable C# libraries that matches C++'s (incl ATL et al).

C# vs. C

Nick Parker — Thu, 27 Jan 2005 05:13:00 GMT

re: C# vs C++

Joel Barciauskas — Thu, 27 Jan 2005 03:01:00 GMT

Languages are all about the right tool for the right job. Now, C# has made some advancements, making it appropriate for a wider range of jobs, but when we get down to it, you're still not going to write kernel code or device drivers or programs for extremely limited resource systems, where manual memory management is a necessity. As Alex said, the Windows desktop/server world is not all there is.

On the flip side, there are some great uses for Perl that C# will probably never be able to compete with.

re: C# vs C++

Jim Lyon — Thu, 27 Jan 2005 03:34:00 GMT

"What did I miss?" Two more for the C# side:

1. C# avoids many of the dark, obtuse edge cases that follow from the not-quite-ortogonal features of C++. An example is the infamous "What happens when you call an overridden virtual method from a virtual base class's constructor?" By not having virtual base classes and not having weird rules about when overridden methods come into play during construction, C# avoids the issue. There are many, many similar questions in C++.

2. In modern C++, the obvious tool for the job is seldom the right tool. For example, in the modern world of STL and exceptions, you should almost never use the fundamental types of the language like pointers and arrays. Which leads one to the question "if you're not supposed to used them, why are they there?" C# on the other hand is designed so that the obvious way to code something is usually the correct way.

re: C# vs C++

Gerd Riesselmann — Thu, 27 Jan 2005 09:45:00 GMT

I second missing deterministic destructors as one of C#'s biggest annoyances. IDispose isn't quite the same and it's design is a bit clumsy for my taste, since you end up with repeating code including a member variable. It seems to me this would have been better implemented on object using the template method design pattern (function dispose on object that handles multiple calls and calls a protected member function onDispose() that can be overridden).

An advantage of C# above C++ are events. Though there are libraries that bring events to C++, they all are a little bit complex and require quite an effort. It must be said, though, that C# events also are unneccesarily complex compared to the VB6 event mechanisms. To declare and trigger an event, there's too much stupid code to be written - and suport from the IDE is missing more or less completly.

This may be due to events relying on delgates. Delegates, however, are also a very nice feature, since they handle function pointers transparently. Typedefing a function pointer in C++ on the other hand always makes my head ache.

.::Szőkelizer 123::.

RIO - Randektív Informatikai Oldal — Thu, 27 Jan 2005 13:17:00 GMT

<p><ul><li>Nehéz és hosszú szülés után... ami főleg időhiánynak köszönhető... kérjük azokat, akik szívesen olvasnak (=azt a keveset), hogyha talál vmi érdekeset, akár el is küldheti :)</li><li><a href="ht

re: C# vs C++

DrPizza — Thu, 27 Jan 2005 11:54:00 GMT

C++ has a set of collections classes that are worth a damn.

C# has the .NET libraries, and they're complete crap. Lacking in orthogonality, poorly-named, incomplete, and all-round inadequate.

re: C# vs C++

Bas Westerbaan — Thu, 27 Jan 2005 12:11:00 GMT

"C# has the .NET libraries, and they're complete crap. Lacking in orthogonality, poorly-named, incomplete, and all-round inadequate. "

I disagree, the naming is very consistant which is way more important than nice naming although in my opinion .net uses good naming.

In C#2.0 there will be generics which are like templates but type safe (in c#2.0 i can do stuff like List<int> aList; etc..)

IDisposable isn't a replacement for the desctructor but rather a way to make sure when you call Dispose an object's possibly native resources are disposed. You shouldnt use IDisposable if you arent dealing with native sources or other IDisposable.

I can't see a memory operation you can't do with C# that you have to use in most applications. (If you want to be sure an object is finalized and deleted use GC.GarbageCollect).

The biggest advantage is productivity. C# owns C++ in productivity. The .net class library is way easier to use (I seldomly have to look in the documentation to find out how a class works), in C++ i got to check all this stuff for the naming just sucks. C# lets you make way less bugs, using references instead of pointers really helps. Also not having to care about deleting objects is a great help. etc.. etc..

re: C# vs C++

DrPizza — Thu, 27 Jan 2005 13:59:00 GMT

"I disagree, the naming is very consistant which is way more important than nice naming although in my opinion .net uses good naming. "
The naming is not consistent with what the collections actually are.

I don't give a hoot about internal consistency; what I want is for things to be named what they ought to be named.

Though the .NET libraries are obviously much larger than the C++ libraries, it seems to me that about as much work went into the design of the C++ libraries as went into the entire .NET class library; the result of this is that the C++ libraries are more expressive and more capable than their .NET counterparts.

re: C# vs C++

Erno — Thu, 27 Jan 2005 15:30:00 GMT

I missed the CTS

(How many different string types are there in C++ again? Ever tried to pass a date(time) to a database?)

re: C# vs C++

Denise — Thu, 27 Jan 2005 17:28:00 GMT

It would be nice if you didn't need to force someone to install the entire .net framework because you chose to write in C#.

Since the framework is not a required download and has never been part of any major patch the majority of the Windows desktop world doesn't have it installed.

re: C# vs C++

Bas Westerbaan — Thu, 27 Jan 2005 23:14:00 GMT

http://blog.w-nz.com/archives/2005/01/27/negative-net-myths-busted/

Interesting Finds so far this week

Jason Haley — Fri, 28 Jan 2005 03:38:00 GMT

Interesting Finds so far this week

My $.02 on C# vs. C

TheChaseMan's Frenetic SoapBox — Fri, 28 Jan 2005 21:12:00 GMT

re: C# vs C++

ScanIAm — Fri, 28 Jan 2005 20:49:00 GMT

A few people have mentioned a dislike for the lack of deterministic destructors in C#.

I would like to say that it took me a while before I figured out the beauty of NOT having them. Over time, C++ caused me to blur the concept of 'shutdown my object' with 'free my object memory'. These two items are distinct and different. Now, I 'shutdown my object' and let the OS worry about 'freeing my object memory'. It is rare that I care about the freeing of the memory, but I DO want to know that my object has been shut down.

Sca

re: C# vs C++

Lington — Sat, 29 Jan 2005 16:06:00 GMT

C++ is not a dead language.c# is a version of C++ and has its own loop holes as well.
In my own opinion C++ will continue to be the best language everywhere,its library its hard-core.You can develop any applicattion you want (i.e: text base and graphical).
It might be inflexible some somehow especially with its case sensetiveness.

Programmer Lington(Delphi/c++/Oracle)

Eric Gunnerson - C# vs C

Forest Blog — Mon, 31 Jan 2005 18:07:00 GMT

C# vs C

Agus Kurniawan — Tue, 01 Feb 2005 10:34:00 GMT

C vs C#

markda's WebLog — Wed, 02 Feb 2005 03:46:00 GMT

C vs C#

RGabostyle.com — Wed, 02 Feb 2005 04:35:00 GMT

C vs C#

RGabostyle.com — Wed, 02 Feb 2005 04:50:00 GMT

re: C# vs C++

A. Riyadi — Sat, 05 Feb 2005 07:18:00 GMT

I think, both are best. It depends on what will build. Programming language is only a tools. Don't be an extreme programming language. Some can solve many things that some could not. So, it depends on situations. As a technology preview, C# still need evolution(maybe) that makes very..very different from C family. So, what should M$ deals with ?

re: C# vs C++

govindarajan — Thu, 10 Feb 2005 11:44:00 GMT

i have a CPP and H file and also dll created created using the same files.

insted of this i able to refer the dll into my C# project. it is not work.

how to convert the cPP and H file into C#

plz send details about that to Govindarajan@teembrains.com

re: C# vs C++

Michael Bosley — Wed, 16 Feb 2005 17:40:00 GMT

My biggest issue with C# is that it promotes "lazy" programming practices. Not that I want to sound like a drill instructor or anything, but if you can't write good code without the helpers, then you're going to worse code with them. (that makes me sound too much like a purist, but I can't think of a better way to put it)

If all objects in C# are just variants, it is going to be inherently inefficient. If I want to compare, for example, a number and a string, both would have to be converted to strings. Because I can call (x == y) with two different types in less code doesn't make it better. It does make it easier, but see my first comment for thoughts on that.

I don't consider the garbage collector a significant improvement to the current method of "what you malloc you must also free." But that's a personal opinion - some people love it. It is nice, however, that it does it during downtime so I don't have to wait for delete/free to return... but I could do the same thing with a low priority thread.

In C#, there isn't a header that a developer could look at to see an object's accessors/methods/functionality. The developer either has to read the code or get additional tools to parse the code for them. For badly formatted code (95% of us) this is tedious and error prone.

In C#, you have to state the obvious far too often. For example, to pass something by reference, both the caller and the callee have to know it's by reference whereas in C++ only the callee needs to know. If I want an overloaded function (or member, or accessor if you like those terms) I have to say "This can be overridden!" and then I have to say "This overrides that!".

const. There is no guarantee that I won't change your data.

Maintainability. In C#, if pass by reference changes, both ends (callee and all the callers) must be changed. Alternative argument: it's an api change.

Efficient code is harder to write in C# than C++. (use the right tool for the job)

Small applications have a huge startup and huge memory imprint. Large applications that need to manage memory tighter, as others in these threads have stated, shouldn't be done in C#.

Like Java, in order to use software developed for .Net, additional software is required to be installed. To use a coworkers phrase, it's "coupling, gone evil-bad." ;)

re: C# vs C++

Eric — Wed, 16 Feb 2005 17:53:00 GMT

Michael,

I started to write a comment that addressed your points, but I ended up deleting it to make a general comment instead.

While you do say some things that are true, it's clear to me from mistakes in your comment that you haven't really used C#.

re: C# vs C++

Michael Bosley — Wed, 16 Feb 2005 19:52:00 GMT

Sorry, I forgot to say that I haven't used it a lot. I'm still a newbie when it comes to C#, but I've been a professional programmer for the past 10 years and have developed unprofessionally before then.

Please, feel free to comment and show me where I'm wrong... I'd like to know so I can learn and so other people don't get the wrong ideas from what I said. :)

The one comment that I know is at least "off base" is the "Small applications have a huge ..." bit... I started rethinking that right after I posted, but thought I'd let others correct me.

re: C# vs C++

Eric — Thu, 17 Feb 2005 01:06:00 GMT

Michael,

I'm happy to write comments here. If you'd like to take this off-line into email, that's okay as well.

Here are my thoughts:

1) Objects in C# aren't variants. Reference types are heap-allocated the way that heap-allocated objects in C++ are (though on a managed heap), and can be converted to the type "object" merely by upcasting (since all reference types inherit from object).

Value types are more complicated - they are stored as you would expect (ie a 4-byte integer is stored in 4 bytes) - but are convertible to object through boxing, which makes them into heap objects.

2) In general, you can't call == on two different types (or you can if you cast them to object, but they'll never be equal). C# does not do the weird (IMO) thing that VB does of trying to do something in this case. You can make some comparisons between different types if the appropriate conversions exist, which is very similar to C++.

3) Not having a header is a big advantage. Yes, you need a tool, but they're easy to find, and having good metadata enables a ton of useful scenarios - not the least of which is much improved intellisense in IDEs. I spend much less time reading docs in C# than in C++ because of this.

4) The decision to require ref to be placed in both places is deliberate, so the caller is clear that it's being used. Ref is pretty uncommon in C#, since return values aren't used for status.

5) virtual and override are both there to make versioning better. See the reference below for more info

6) On the subject of efficiency, it's not clear-cut to me. I can get lower into the machine when writing in C++, which gives me an edge there, but I can write code much faster and with less effort in C#, so I have more time to spend on optimization.

7) Small applications do take lots of memory and startup time, and that is a drawback of C#, as is the requirement to install the runtime ahead of time.
You might also want to take a look here:

http://blogs.msdn.com/csharpfaq

link exchange

heller — Sun, 20 Feb 2005 04:49:00 GMT

http://kghsjg.k1.xrea.com/ ,http://hls.k2.xrea.com/ ,http://eom.k2.xrea.com/ ,http://www.soudown.net/ ,http://www.998guide.com/ ,

C# versus C++

aspnetguy's blog — Mon, 21 Aug 2006 22:39:06 GMT

Being asked this lately I thought I would post it on the blog for everyone to see and decide for themselves.

what next - FeverGaming

what next - FeverGaming — Sat, 10 Feb 2007 21:39:07 GMT

PingBack from http://forums.fevergaming.com/off-topic/programming-web-development/122259-what-next.html#post1763754

C# vs C++ - Programming Support

C# vs C++ - Programming Support — Wed, 31 Oct 2007 03:44:56 GMT

PingBack from http://www.se7ensins.com/forums/programming-support/81624-c-vs-c.html#post622078

Magic of C# with respect to C++ « Syyed Wahab’s blog

Magic of C# with respect to C++ « Syyed Wahab’s blog — Tue, 11 Dec 2007 22:52:00 GMT

PingBack from http://syyedwahab.wordpress.com/2007/12/11/magic-of-c-with-respect-to-c/

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

Why exactly is C# better than C++ (was Re: Up to date MFC Book) | keyongtech — Thu, 22 Jan 2009 04:11:24 GMT

PingBack from http://www.keyongtech.com/736774-why-exactly-is-c-better

Eric Gunnerson s C Compendium C vs C | Green Tea Fat Burner

Eric Gunnerson s C Compendium C vs C | Green Tea Fat Burner — Mon, 08 Jun 2009 05:17:45 GMT

PingBack from http://greenteafatburner.info/story.php?id=1788

Eric Gunnerson s C Compendium C vs C | Quick Diets

Eric Gunnerson s C Compendium C vs C | Quick Diets — Tue, 09 Jun 2009 14:31:08 GMT

PingBack from http://quickdietsite.info/story.php?id=14356