Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a coder and have experience with both native and managed code. I started out with Pascal and C, then moved into C++ and eventually into C#.

Over the last year or so, I've been coding almost exclusively in C# and have lost a lot of what used to come naturally when I was a C++ coder.

A few weeks ago when I sat down to write some native C++ code, I found myself fumbling around as I slowly got re-acquainted with the complexities, quirks, and idiosyncrasies of it all. I'm almost embarrassed to say that I had completely forgotten that passing a dynamically allocated array to a function without also passing its size would mean that the receiving function would have no way of knowing how long the array is.

There are countless articles and documents which compare and contrast managed vs unmanaged code. We all know that native code, if well optimised, can run significantly faster and lighter than managed code. On the other hand, managed code has garbage collectors and run-time CPU-specific and OS-specific optimisation which can give native code a run for its money.

Purely from a technical perspective, there is no clear winner.

There is no doubt that managed code is orders of magnitude simpler to code and understand. Just look at difference in the number of lines necessary to construct a simple GUI in Win32 C++ vs C#.

Back in my native-coding days, I mostly wrote mathematical simulations that ran on supercomputers. They had ugly CLIs and were mostly algorithm-focussed. Nowadays I write in C# and produce beautiful GUI applications, but would be lost if I had to make something of a similar calibre on a native language. Even with a framework such as QT, it would still take twice as long to produce something in C++/QT than it would in C#.

Whenever I see someone who has written a large-scale, full-featured GUI application in C/C++, I can't help but feel a sense of awe and a hint of jealousy.

I'm curious how other experienced coders see managed and unmanaged languages. Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

share|improve this question

migrated from stackoverflow.com May 10 '11 at 5:59

This question came from our site for professional and enthusiast programmers.

12 Answers 12

My day job is currently in C++, but I've programmed in several languages long enough that I barely notice a difference anymore. Here are my observations:

  • A lot of the alleged inefficiencies with other languages are frequently reimplemented by C++ programmers as best practices. We add enough null checks, array bounds checking, type checking, input validation, etc. to largely negate any execution speed advantage gained by the language not automatically doing those things, at least for code that isn't data processing intensive.
  • That extra boilerplate becomes an ingrained habit after a while, so that it doesn't really feel like extra work, and sticks out like a sore thumb when it's missing.
  • When I program in a "managed" language I still think about memory allocation, so as to make sure I don't create a memory leak. I may not be putting an explicit delete, but I'm still aware in my mind of the point at which the garbage collector considers it eligible for deletion. I had more difficult to solve low memory issues starting out in Java than I ever did in C++, probably because in C++ they are much harder to ignore for very long.
  • Same goes for dynamic typing. I still have to keep track in my head of whether a function parameter is an array, or an int, or a string. In fact, it requires more mental effort because the type isn't plainly listed right there for me.
  • Modern C++ style is very different than the pre-C# era. Rather than the language changing, people "discovered" how to use existing C++ features in unique ways to avoid much of the menial memory management of the past. Design patterns that free memory automatically are very common now.
  • As far as I know, even though it's possible to make GUI applications by only writing code, graphical designers like QT designer are the vastly preferred method, with code mostly only used for event handlers or runtime customization.
  • Languages you haven't used extensively in a while always feel a little clumsy, even if you mostly remember the syntax. If I don't write python for a year, there are a lot of idiosyncrasies I have forgotten, and it feels more awkward than C++ for a while, even though objectively most people consider python the "easier" language.

With the combination of all those factors, my mental model stays fairly consistent between when I program in C++ and other languages, and the differences feel mostly merely syntactic. Granted, a lot of that is a result of training, habit, coding standards, and modern design patterns rather than features intrinsic to the C++ language itself, but the comparison still stands.

I guess what I'm trying to say is that in my experience the programmer's training makes a lot more difference than the language he is using.

share|improve this answer

Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

No.

I see the differences between an engineer and a programmer. The hardcore engineer will always choose the language/tech stack that's appropriate to get the job done in the least amount of time at an acceptable runtime standard.

With processor power these days, the frequency of actually needing to get as much as you can out of a machine by using lower level, native languages is getting less and less. There usually really just isn't a business case for it. Productivity will always trump a few milliseconds difference in execution time.

share|improve this answer
    
+1 but bear in mind that this is an economic effect - if a compute cycle cost $1m then extreme optimisation would rule - or we'd not bother with computers at all... –  Gary Rowe May 10 '11 at 8:45
10  
except that we do see lower performance overall - Word6 runs like lighting on modern hardware, Word2010 takes a minute just to load. Today we need that superfast hardware to keep up with the programmers! –  gbjbaanb May 10 '11 at 10:21
2  
@gbjbaanb: No matter what programmers choose, any sufficiently large codebase is going to be slow. IIRC, Word is still written in C++ (and I'd be willing to bet that a significant portion of all of the legacy Word 6 code is still there). –  Steve Evers May 10 '11 at 23:21
1  
@gbjbaanb, Word 2010 is not a straight rewrite of Word 6 in .NET. It adds many more features and has to handle many more usage scenarios. It's a much, much larger application than Word 6. –  Mircea Chirea Apr 25 '12 at 19:54

Sadly, Microsoft has lead us to conflate "Managed Code" with the C#/.Net class Libraries.

There are two separate and almost unrelated things at play here.

  1. Cool .Net libraries.

  2. Managed code.

C# offers both in a tidy, supported, easy-to-use package for one price.

C++ has numerous cool libraries that do almost everything .Net does. Rather than blame "native C++" code as being having more "complexities, quirks, and idiosyncrasies" than C#/.Net code, you could look for better C++ libraries.

Better libraries allow you to write nice C++ code, also.

Whenever I see someone who has written a large-scale, full-featured GUI application in C/C++, I can't help but feel a sense of awe and a hint of jealousy

Bad policy. Instead you should find out what libraries of class definitions they used. You, too, could use those libraries.

It's all about the tools. Without tools, we're just animals in pants.

"Native C++" does not mean you should throw away all your tools. It means you have to find good tools. Microsoft is no longer helping you, so you need to spend time finding the right mix of tools.

share|improve this answer
    
+1 for the "go find out what they're using", but frankly I think this isn't very nice to tool-using animals, or animals that happen to wear pants on occasion. –  Ian Pugsley May 10 '11 at 12:33
    
@Ian Pugsley: The animals that wear pants but don't use tools are probably okay with their status as animals. But you're right that the tool-using animals without pants might get upset. My wife, for example, prefers not to wear pants, and does use tools. Perhaps she won't read this question. –  S.Lott May 10 '11 at 13:06
    
We can only hope (and bet on the fairly-high chances). All I'm saying is I'm not gonna look down on an animal smart enough to put on a pair of pants...just in case. –  Ian Pugsley May 10 '11 at 13:15
    
Yeah, unlike C#'s standard library, C++'s is old and lacks of modern needs (GUI, cool networking interface, etc). –  Zippoxer Jul 22 '11 at 13:26
    
Microsoft is once again helping you with C++ in Windows 8 (the entire Windows 8 development surface is native code, and C++ is a first class citizen along with C# and JavaScript): msdn.microsoft.com/en-us/library/windows/apps/… –  Zach Oct 17 '11 at 6:35

The issue here isn't about hardcore programming or anything like that, it's about control. The fact is that C# offers productivity at a cost of control. If you're writing a program that needs a high amount of control (this memory is deallocated exactly now), then you have no choice but to use C++. If you need to get it done quickly, then you may need to use C#. The issue is that the supporting libraries for C# are much better and more recent than provided for C++. For example, MFC is very, very old and it's practices are known to be terrible, it was mostly written long before Standardisation. If Microsoft put some effort into providing new C++ libraries, for example, check out the new PPL in Visual Studio 2010, then strangely enough, that task becomes easy in C++. And I think that they are migrating that way, because they realized that managed code doesn't solve every task.

On the other hand, managed code has garbage collectors and run-time CPU-specific and OS-specific optimisation which can give native code a run for its money.

I've heard many managed language proponents say this, but I've pretty much never actually seen it to be true. The fact is that the new CPU instructions available in newer CPUs simply don't offer that much of an advantage unless you're doing very hardcore mathematics, in which case you can't afford the overhead of having to compile or interpret it at run-time and you could just use Intel's C++ compiler to use the latest and greatest in SSE anyway. The scope of C++'s compiler optimizations is massive compared to what the JIT can do, because the JIT has to execute in a fraction of the time whilst the program is running, whereas C++ compilers are pretty legendary for taking their sweet time to compile.

Garbage collection is not some kind of magically great thing or something like that- it's an algorithm choice. Is it appropriate for all situations? Not by far- look at the IDisposable mess in C# and how Java didn't even bother to try with that issue, whereas C++'s destructors will close your files and free your memory and close your sockets, etc etc. GC is great for some programs, and not for some others.

share|improve this answer
    
There's more to differences between processors than SIMD - although your C++ compiler is probably taking the pipeline into account just as much as your JIT. –  Peter Taylor May 10 '11 at 22:52

In my opinion native C/C++, comparing to C#, looks like assembler to C/C++ itself. Another complex layer of abstraction (not exctly true, but let's say so) as always, gives you easier development, but some reduction in speed and some excessive memory usage. So, as I see it, it's just splits to different categories, thus creating new subtypes of programmers.

Btw for it's level of abstraction C# is incredibly fast, microsoft did an excellent job.

share|improve this answer

There are amateurish programmers, not amateurish languages. Languages they have all (well, most of them at least) their purpose.

I am currently co-working on a insurance calculating engine used to test the production system. The production system has been made in C, our engine is done in Java and since longer time we outperform the C engine, being at the same time much more productive. Not because Java per se is faster than C, it is just fast enough and our algorithms are better, we have implemented them more easily, we could faster and better test and refactor our code.

I also wrote testing code to compare calculation results with the content of production database: not in C, not in Java but in Ruby. Again, it is fast enough and needs much less code so is easier to implement, easier to test, easier to expand.

And I don't feel amateurish no matter what language I use, I feel that way only if I make a stupid bug that shouldn't have happened.

share|improve this answer

Last year the firm I work at were reverse engineering a communications CRC code by brute force (we got it eventually). 3 Developers each had there own version, Borland C, C#.Net 2008, VB6. VB6 was obviously slow, Borland C was quick but the C#.net just flogged it by 12 times the speed. Wasn't what we expected at all.

share|improve this answer
1  
Are they using the same algorithm step-by-step? They could be computing the same output but the elementary mathematical steps used to arrive at the output might be different, and performance is determined by the raw count of elementary steps, which in turn is determined from how the "formula" is decomposed into them. –  rwong May 10 '11 at 6:10
    
An older C compiler may not be using the latest processor instructions (ie, SSE2 and later) –  GrandmasterB May 10 '11 at 6:31
1  
All three languages compile to optimized native code (VB6/C++ during compilation, .NET during JIT). So you're probably measuring differences between your programmers rather than between the programming languages. –  nikie May 10 '11 at 6:47
    
@nikie JIT != compilation. And the quality of compilers differs. I've seen exactly the same algorithm execute much faster when written in C++ (no API calls, just array references, loops and simple arithmetic) than in Java, despite all the talk about JIT. –  quant_dev May 10 '11 at 7:07
1  
@quant_dev: In my experience there is no silver bullet ;-) My experience with the .NET JIT is that the difference between JIT and MSVC++ is very small. I very much doubt 12x either way for the same code. –  nikie May 10 '11 at 7:26

It depends on a mix of things, but basically, all else being equal, yes, native code is more "hardcore" than managed code.

I guess that's usually a bad thing, though, for a normal business application, because it means the average developer must put more mental energy into non-business aspects of their code.

share|improve this answer

My program is what could be best described as C++ like Java. My opinion is you can achieve the same low level programming in Java, but it is much harder than low level programming in C++. However, you usually need this low level programming in a small fraction of your code and where it is not required a managed language is more productive.

share|improve this answer

Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

There's a gap between the two world, and I can't see why: managed systems are somewhere written in native code (as final, everything runs "in assembly"). What I want to see (yet in my life) is an application constructing system, where all the sub-task of the application will be written in the right language type.

share|improve this answer
    
An application constructing system as you describe is just another (and hopefully better) programming language. –  David Thornley May 10 '11 at 21:49
    
I'm not familiar with .NET, but AFAIK it's a mixed language system, which have a common executable format run by a VM and a massive library which can be used with any .NET language. A same system would be nice in native/compiled world. Platform-independant, of course. –  ern0 May 11 '11 at 6:40

Native developers usually get the reputation for being more hardcore because they feel more hardcore and act that way. Native developers are trained in a system not tolerant of any mistakes because they inevitably lead to hard crashes or unbounded memory leaks. In particular, .NET allows lazy hacks like putting try/catch around everything, saving the developer from thinking they have to understand the core issue ("sometimes, it just throws InvalidOperationException. I can't explain it, let's just catch everything. This code is critical!"). This isn't at all black and white, but are my observations having grown up in the unmanaged world and now working in managed code full time.

In addition, managed developers also tend to have access to far cleaner and more organized BCL's. This often encourages them from exploring what actually happens under the covers. True, the same can be said for, say, STL or Boost, but the .NET class library is often good enough to make us intellectually lazy at times.

That said, writing a good, shippable managed program takes a lot of work. That means doing memory and CPU profiling, unit tests, and code analysis in similar ways that unmanaged developers do it. Unmanaged developers tend to understand this going in, and managed developers tend to include more of those who don't.

Again, not black and white. There are many intellectually lazy unmanaged developers and hardcore managed developers. Neither is by definition more elite than the other.

share|improve this answer

Native code got easier since Go was released. And that's not my opinion, but a fact. I find it easier than Java (that was an opinion). Although GUI programming with Go, as of now, is not very nice (I took a quick look at the options).
Try not to judge it for it's lack of large community and variety of libraries compared to C# (for example), because it's still considered new.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.