views:

1372

answers:

16

I'm only curious. I have already developed microcontroller software in C and Assembly. So, I can see an application for these languages.

As for today, I'm specialized in information and process systems and even though C++ is object-oriented and offers powerful development capabilities, we mostly develop in .NET C#.

So my question is this:

Which applications are best developed in C++ over C# in today's business?

Thanks for your serious responses!

+4  A: 

That's a strange question. Since Linux and Mac OS don't readily support .Net, then you would not use C#.

If you want open-source software -- unencumbered by Microsoft licenses or patents -- you'd use C++.

S.Lott
Could the downvoter explain why -- I think @S Lott's explanation is reasonable.
High Performance Mark
Linux supports Mono and thus C#.
Henk Holterman
+1 I totally disagree with the downvote. This gives an exact explanation answering my question.
Will Marcouiller
@Henk You are technically correct but still Mono is considered a second class citizen in Open Source world. Yes I know there are a few popular s/w in Mono but still its very very few compared to other languages
Tanmoy
OS X supports Mono also.
James
@Henk: There is a not-insignificant number of Linux users who will not run Mono, due to IP concerns. Python tends to win on linux simply because of that.
jkerian
I'm not going to downvote, but please explain how anything written in C# shackles you with Microsoft licenses or patents.
Jesse C. Slicer
@Jesse C. Slicer: http://www.microsoft.com/interop/cp/default.mspx sure likes like "This promise by Microsoft is not an assurance that..." patents are not infringed. It appears that there's still a chance that an enforceable patent may interfere with your use of C#.
S.Lott
@Henk - I think you meant to reply to @jkerian.
Jesse C. Slicer
@S Lott: There is plenty of open source software written in C#. Even if Mono resulted in IP problems, the software written in C# would still be open source. Categorizing all C# software as closed source is simply misleading. @Tanmoy: It may be considered a second class citizen, but more because of tradition than major IP or technical problems.
Billy ONeal
-1 already explained by others regarding mono.
Chris Marisic
@Billy ONeal. "There is plenty of open source software written in C#" Indisputable. It's very popular. However, the remote possibility of legal entanglements still exists.
S.Lott
@S Lott: If you think that, then why did you write your answer that way?
Billy ONeal
@Chris: The simple fact is that C++ programs will normally run on Linux and Mac OSX, while Mono-based programs often will not. Moreover, everybody on Linux or Mac OSX has a C++ compiler immediately available, while not everybody has a C# compiler. Until Mono is normally shipped as part of Linux distros and Mac OSX, and C# makes it into the Gnu compilers, C++ will be a better delivery vehicle than C#.
David Thornley
@Billy ONeal: I'm not sure I get your question. There's open source encumbered by potential legal issues and there's open source unencumbered by any legal issues. C++ is a way to assure no possible legal issues. I think that's what I said.
S.Lott
@David Thornley Mono is used by part of the Gnome project now; a lot of Gnome distros include it by default and it's generally trivial to install on those that don't.
James
+15  A: 

Off the top of my head, anything low level such as drivers. C# doesn't provide a lot of lower level access, and anything relying on system APIs usually achieve this using dllimports anyway.

Also, anything that requires a low memory footprint is best done in C++ where the developer can manage the memory directly (in my opinion).

EDIT: If you do some searches for C++ vs C# performance, you'll find some hits. I found an article here, and though its a bit old, it's probably still relevant. C++ these days is still very good on embedded devices where resources are limited. You have to take execution environment into account. C# has a lot of checks in the runtime that aren't done in C++. C# is definitely safer and less error prone, but that comes at an overhead cost.

SB
-1, you have just as many options for managing memory in .NET as you do in C++
Chris Marisic
@Chris: Yes, but you cannot force deterministic reclamation of memory in .NET.
Billy ONeal
What specifically are you stating that can't be done with unmanaged .NET?
Chris Marisic
@Chris: Err.. there's no such thing as unmanaged .NET.
Billy ONeal
Regarding memory management, I guess it depends on your team and their skill set. I strongly suspect that most developers are not nearly as good at memory management as the .NET garbage collector.
Tim Goodman
+1 for device drivers. The entire OS X IO subsystem is written in a (fairly restricted subset of) C++.
JeremyP
+5  A: 

games - I mean serious game (AAA), for Indie games C# + XNA is awesome ;-)

multiplatform - but here you have f.e java

nilphilus
Is there a reason a top level game couldn't have most of the code written in C# and then have the real critical graphics modules written in C++?
tster
@tster: marshalling between C# and C++ is not that fast and easy, and performance is very important for games. Additionally there are the portability issues of C# (although you have to be careful with C++ aswell, to get portable code)
smerlin
A rather large number of games these days just license a pre-existing engine and implement a great deal of the core game logic in Python, Lua or some other language suitable for easy scripting. The performance considerations are largely isolated to the engine developers, whereas the game developers focus on the content pipeline and ease of content development.
Dan Bryant
+9  A: 

PC Game dev is almost exclusively C++. Also, every application that needs to get the most out of the hardware at all costs, should better be developed in C++ than C#. E.g. physical processes modeling, cryptography, performance-critical web app modules etc.

buru
Almost; although there have been notable exceptions (The Crash Bandicoot games were written in Lisp). There's a lot of game scripting done in LUA and Python as well. For smaller teams, there's been an increased push toward C# and ActionScript recently.
James
@James: I believe the question was about C++ vs. C#, not C++ vs. EVERY_OTHER_LANGUAGE_HERE.
Billy ONeal
I was elaborating on the "almost" and noting that C# is becoming a larger part of it.
James
There are plenty of games that use C# since XNA started to mature. For a 'bigger' example, I think Neverwinter Nights 2 was, but not sure and can't be arsed to look for that information or dig out my dvd.
Alex Paven
NWN2 used C# for the toolset, but the core engine was still C++. Same way with most professional game engines--you're not going to see C# for anything that has to run on Sony or Nintendo platforms.
ChrisV
+7  A: 

Portability issues aside, everything where performance is important.

I'm not talking pure number crunching or gaming. I'm talking applications that need to do things fast (relative to what the user expects) and/or with a decent memory footprint. There's a reason that Visual Studio is not written in dotNET. Or Photoshop. Or Internet explorer. Or MS Office.

dotNET/C# is great for creating GUIs, but if the application exceeds a certain size/complexity it seems that C++ GUI apps still are way ahead in responsiveness etc.

Martin
Visual Studio 2010 is written in WPF and it means C# (or VB)
Tanmoy
@Tanmoy - indeed! I'm still unsure what parts of it are .NET though
Martin
I could swear I read somewhere MS Office was written with .Net/C#, is this not true?
James
-1, building incredibly fast applications are hard regardless of language, it just requires correct design, this can be just as validly done in .NET as C++
Chris Marisic
The reason Photoshop and IE and Office are all written largely in C/C++ is because those are the languages that were around in the 1980s and early 90s, when they were created.
quixoto
@James: To learn is a software product uses .NET, just use something like Process Explorer and among the loaded dlls, look for .NET runtime.
Nemanja Trifunovic
@Chris: The language is relevant for performance. Some languages require features that invariably lead to degradation of performace (array access checking, for instance) while others alow unsafe features to help compiler produce faster code.
Nemanja Trifunovic
@Chris: Having seen both .NET and C++ (and Java) GUI development all *I* can say is that it is lots and lots (and lots) easier to mess up application performance with .NET (or Java) than with any C++ GUI library I ever worked with.
Martin
+11  A: 

Any kind of large data processing/manipulation (I've seen this with imagery, and stock market data) tends to be better done in C++ for the performance, plus there are tons of C++ libraries (like intel performance primitives) for doing high performance things.

Jimmy Hoffa
+2  A: 

Modern libraries have a tendancy to be written in C++ (It's just so much easier to work with than C). C++ provides an advantage here in that almost every newer language provides a way of linking with either C or C++ based shared object libraries, usually with fairly simple mappings.

EDIT: C# is not appropriate for library development, because that would artificially limit your userbase to a very small subset of what it would otherwise be.

jkerian
Err. the question is C++ vs. C#, not C++ vs. C.
Billy ONeal
Yes... obviously... but C is the other (as common or slightly more common) option for library development. C# doesn't even deserve a mention in this context.
jkerian
@jkerian: That may be true. But you aren't answering the question that was asked.
Billy ONeal
@Billy: Really!? Please re-read the question: "What applications had better be developed in C++ over C# in today's business, I wonder?" Sorry... I presumed that was "application of the language", library development is definitely an application of a programming language... or... what's your objection?
jkerian
@jkerian: Your edit makes this answer acceptable; I have removed my downvote. But your original post looks very much like a C++ vs. C comparison.
Billy ONeal
+1 with regards to your edit.
Chris Marisic
The edited answer may be technically valid (second part of it), but pretty rude. -1
Nikita Rybak
I'm going to say that C++ is a pretty poor language for writing libraries. Thanks to the fact that there is no commonly agreed C++ ABI, a pure C++ library will often only link with code compiled with the same compiler, sometimes with the same version of the same compiler (I'm looking at you g++).
JeremyP
@JeremyP: While true, there are effectively de-facto standards now on all the major platforms. The cross-language interface mechanisms are pretty good at understanding the various permutations of name-mangling. Borland C++ is probably the biggest "minority player" in this space.
jkerian
+2  A: 

C# is a very nice language, in Windows/.Net/Visual Studio/C#, programming is much more pleasant and efficient than with c++.

But the performance is a downside. Also in C# its difficult eficiently manipulate binary files or custom formats, you must use Win32 APi for that.

Adesit
Err.. I'm not the most experienced C# programmer in the world, but what's wrong with [`BinaryReader`](http://msdn.microsoft.com/en-us/library/system.io.binaryreader.aspx) and friends?
Billy ONeal
-1, .NET performance is fantastic.
Chris Marisic
we had an issue, porting an application reading large custom format files from c++ to C#. The C++ solution needed about 3 or 4 minutes to start, the c# solution over 20.
Adesit
@Adesit, a single instance does not validate an argument. Also you said ported that alone implies performance issues were developer faults. Performance can always be improved, but the question is was it even right to port it to start with? If it was already successful and performant why didn't you just call the C++ DLL to do the work instead?
Chris Marisic
Normally you dont want to read a basic datatype like byte or char etc., what you really want is to fetch n bytes from specific place in a file into your specific data structure (a struct). With fread() anf fseek() you are fine. Is where a comparable solution in C#, without using Win32 API?
Adesit
@Chris Marisic The reason for the port was that at once the application had to support a bunch of MS communication protocols and it was decided to rewrite it using C# and WCF. The data files remain the same..
Adesit
That goes back to my comment, why did you port the file manipulation portion if there was no cause for it? Having cause would imply you manipulate the file differently in some way with .NET.
Chris Marisic
@Chris Marisic. What is unclear about that? Sure the port had a reason, some new features were easier to add in C#. Do you suggest reading data from disk in c++ and use it with C# once its in in operative memory?
Adesit
+9  A: 

Any application which cannot rely on the .NET framework existing on the target machine. The .NET Framework is a huge download (300MB+) (EDIT: Okay, there's the "Client profile" which is "only" 30MB, but when your application is 250k, that's still a huge amount of overhead) and is not supported on older operating systems. For anyone who needs to work when the Framework is not installed or damaged, or needs to support back to Win2k, C# really is not an option.

Billy ONeal
See the [.NET micro framework](http://en.wikipedia.org/wiki/.NET_Micro_Framework).
strager
@strager: The Micro Framework is for CE -- and more importantly it doesn't help you in the Win2k case.
Billy ONeal
@Billy ONeal, I'm not saying your entire argument is wrong, but you can write C# code and target the micro framework and not have a "huge download" for users.
strager
+1 this is one of the few completely valid responses regarding .NET on this thread. The majority of them have major misconceptions which I've commented on.
Chris Marisic
@strager: I don't see what you mean. The Micro Framework does not run on anything but small (Windows CE) devices. At least, I don't see anywhere on the website for it where I can download it...
Billy ONeal
@Billy I believe common usage of the micro framework is to deploy the binaries along side your application binaries.
Chris Marisic
@Billy ONeal, Seems I was mistaken. =] I heard the micro framework has been used, but I didn't investigate *where*. Not on PC Windows, I guess...
strager
The 300MB version of .NET is the offline installer, it contains .NET 2.0, 3.5 and 4.0 for all possible machine configurations. The .NET 4.0 client profile (what 99% of people need to download) is about 30MB.
Fara
@Fara: That's new in .NET 4 iirc -- which I have little experience with. And that still doesn't help with Win2k.
Billy ONeal
If you're using the Mono C# implementation, the interpreter can be even smaller. Although yes, Win2k support may be pretty sketchy.
James
+12  A: 

I disagree with some of the comments here. Given the state of the JVM and the .NET VM "performance" from run of the mill C++ programs are not going to be head over heels better. There will be very little difference (think 5%) unless you're building to the hardware. But...

  1. Any real-time systems where you can't afford a halt or slow down via the GC. That is, you absolutely need true deterministic response times.
  2. Any application which has to interface with hardware components.
wheaties
-1 for your statements on GC, you can develop near real time trading applications with .NET that will never trigger GC slow down with proper technique.
Chris Marisic
@Wheaties: It depends on the application -- For something like a for loop that's going to be JIT'd by the CLR/JVM, performance should be about the same. But "in general" C++ programs are faster than C# programs. That said, the difference is small enough that unless you're doing high frequency finance, I don't think it should be a business concern. +1.
Billy ONeal
@Chris Marisic - I would say in general you are correct but there are situations where you can absolutely not take a chance even with good design. I can think of flight controls, missile counter measures, gyroscopic navigators, and the like. Basically think about systems where lives depend on them performing in a strictly deterministic fasion.
wheaties
@wheaties at that point you're getting into incredibly specialized embedded systems, developing targeting something like that is entirely outside of realms of normal software development.
Chris Marisic
@Chris Marisic: "Near real time" is not real time. I think all of your down votes on this question are harsh.
JeremyP
@Chris: Maybe "normal" to you -- but considering number of machines in active use, the environments C# targets are 10% or less of all computer systems (but 90% or so of desktop systems) -- keep in mind things like cell phones and microcontrollers dwarf PCs in terms of number of machines in use.
Billy ONeal
+3  A: 

I think almost every program which has a gui and should run under windows only and do not rely very much on performance and lots of low level functionality would certainly have benefitted from C#.

I think this is true for most of todays business software.

I also see companies still developing webservices with plain C today, even if performance doesn't matter. They do it just because they have their unix and mainframe machines and they say that it would to too expensive to buy a new machine where Java or C# could be used.

codymanix
+6  A: 

Numerics (ie. crunching numbers).

C# seems to be lacking libraries for doing numerical analysis, even if the language is really really great (I have colleagues who do C# exclusively). But there is a huge body of libraries for efficient numerical stuff in C++.

Moreover, C++ templates are superior to C# generics when it comes to building large code from little efficient pieces, which numerics require: interpolation, root finding, Richardson extrapolation, minimization, automatic differentiation, iterative generic algorithms,... all can be really well combined with templates + inlining from the compiler to yield efficient algorithms.

Howver I really miss covariance of template arguments (one great feature of C#) when I must express things like RandomVariable<T>.

Alexandre C.
What about Math.NET? http://www.mathdotnet.com/
Callum Rogers
@Callum: Because it does 10% of what I want to do, and it does it inefficiently.
Alexandre C.
@Alexandre: The bits it does implement are written in native code, so are probably as efficient as they can be (for the algorithms they use)
Callum Rogers
@Callum: There are no algorithms in Math.Net. Only some functions. No root finding, no minimization, no ODEs, etc. And the random number generation *are* inefficient: look at Intel MKL for something efficient.
Alexandre C.
+4  A: 

Well, the tools that are needed to make C# work. The compiler, the JIT compiler and the CLR are written in C++. But that was more of a bootstrapping problem. Albeit that writing the CLR is a managed language would be close to impossible right now.

The next category are operating systems. But that's changing too, the .NET Micro Framework is fairly popular on embedded systems. But not the really resource constrained ones. And there's the super-secret Midori project at Microsoft. It is a continuation of the Singularity project, a managed operating system. Many of the team members that worked on .NET has joined that project. It's going to be interesting and a potential game changer. If it survives.

Hans Passant
+1 for "cool factor" of this answer :)
Billy ONeal
+3  A: 

The choice of language is orders of magnitude less important than the choice of developer.

In my experience, and outside the individual cases identified in other responses, somewhat non-intuitive factors can determine what gets used:

  • corporate or group policy
  • availability of programming expertise on the team
  • the need to integrate with some
    ancient library that's written in
    VC6.

These days on Windows, for new development the question is not so much "what would you use" as "why would you not use C#". The relative ease of development for all but the most specialized requirements makes C++ a harder sell.

Can't comment much on other platforms but my guess is that there the use of C# is a more uphill struggle, given the smaller population of C#-on-Linux (via Mono) experts, and my lack of conviction that one would prefer Mono to a truly platform-native solution.

Steve Townsend
True; but that doesn't really answer the question.
Billy ONeal
Fair comment, I will try to be more direct.
Steve Townsend
+2  A: 

Applications best developed in C++ over C#:

Any system where memory management requires careful attention

  • Low memory devices
    • 32MB is the minimum for .NET (Mono)
  • Safety and critical systems, particularly where heap allocations are not allowed

Any system where storage is limited

  • The .NET framework is large and trimming it down is difficult
    • Even a 'small footprint' Mono install will be larger than the equivalent C++

Systems where high performance is of crucial importance

  • C# is very fast for the vast majority of applications...
    • ...but C++ will beat it given enough time and effort to optimise
  • Note: The number of system where performance really is that important is a very small niche
    • And remember that the majority of the system could be C#, using C++/CLI where necessary

Take care considering C#/.NET for platforms other than x86/Windows

  • Although Mono is a wonderful solution it isn't perfect
    • Some significant differences between platforms
    • Licensing concerns (even if you don't have them your users might)
  • C++ has it's own set of cross-platform issues but the problems are perhaps better understood
  • C++ can run on almost any hardware
MattyT
+3  A: 

I consider C++ over .NET when

  1. Portability is an issue.
  2. Deployment is an issue (.NET 3.5 for instance not readily available on all target machines).
  3. Startup performance is an issue.
  4. Memory footprint is an issue.

So for example, developing simple windows services for clinet OS in .NET I think is barking up the wrong tree as number 3 is important (Slow starting services may delay boot times which lowers overall user experience of the whole machine).

Personally I am not so concerned about running performance as that is usually good enough in .NET (and one can inject C code in those cases where's its needed).

FuleSnabel