Printable View
A lot are heard about managed vs unmanaged code. I don't want to start a flame war for which is better, but I would like to find out the "truth" on some adv/dis of the two, since I read a lot of contradictory things by searching online.
Being more specific think of C# .NET vs C++ with native code (w/o comparing the languages themselves)
The real answer: there is no "best" solution that fits all needs.
Want to write a FPS game with lush graphics and all the trimmings...probably unmanaged.
Want to work with hardware...probably unmanaged
Want to work with web services...probably managed
And on and on.
The best answer I can think of is that managed code is locked into the dotCrap framework, while unmanaged isn't :p
That basically means you have a huge framework of pre-built functionality at your fingertips vs lots of overhead.
Managed code works best for graphical UI applications. It offers faster delivery and a simpler development process. It's a true RAD, the likes of which we haven't seen before. I find however the code harder to maintain and forces the programmer to depend entirely on the IDE to perform that maintenance.
Compiled code is closer to the bone and a better performer for intensive applications that demand resources from all areas of the computer. It also has a wider scope of applicability, both in types of applications it can serve and the systems it can run on. I find however, it's tougher on the programmer, increases the development cycle, tends to demand a higher number of dependencies and can increase the cost of development due to the technical hurdles it can introduce that require good professionals and longer analysis/debug time.
Managed code has huge advantages in the safety and correctness areas, when developing. A large aspect of both "secure" and "correct" applications can be attributed to memory safety, which .NET provides by allowing you to not have to manage your own memory and deal with it explicitly. There are a lot of gotchas when dealing with explicit memory, and from my own experience, I'd say it's really hard for humans to do properly. The development time for you can be significantly cut because you have fewer burdens as a programmer if you abstract something like this away. Realistically a lot of applications fall into this area. It is much better to have the computer do the unnecessary work if you really don't have to. Another benefit of targeting a managed runtime like .NET as opposed to, say, direct native code, is that it is a lot easier for people writing or prototyping new languages, because you can take advantage of nice, existing infrastructure at no cost. For example, see Clojure, which targets the JVM and CLR: http://clojure.org
On the other hand, certain environments may not be conducive to something like, say, Garbage Collection, which exists in mostly any managed language. There's a lot of research in this area involving soft real-time garbage collection and incremental garbage collection, to minimize GC pause times. This is necessary when timing is a big issue. Locality is also a big issue for garbage collectors because your memory bus will quickly be the bottleneck if the runtime isn't optimized for such conditions (you can do this though.) There are other high level languages like ATS which used advanced type-systems, so in critical parts of your application, you can actually totally avoid invoking the GC explicitly by showing how resources are used. The compiler at that point does the rest and eliminates the GC entirely for that scope. ATS for example, performs very well: ATS speed ÷ C++ GNU g++ speed | Computer Language Benchmarks Game
The GC issues aren't really limited to 'managed' languages that run on .NET or the JVM. They exist equally in any high level language with garbage collection, even if it compiles to native code anyway. Until languages like ATS are more common and polished however, a large amount of systems critical applications where things like memory need to be tightly controlled will likely remain in the realm of unmanaged languages like C or C++, but this comes at the cost of a higher mental load in my opinion, and puts many more burdens on you, the programmer, rather than the language.
I like both managed and unmanaged code but for different reasons and different applications. I do not decide on managed or unmanaged solely on the fact that managed has garbage collection b/c that is easy enough to program in C/C++. Memory management is not a 'draw' for me.
What is a 'draw' for me is that .NET offers a lot of functionality that is very hard to match with raw C++ libraries. It can be done and they are out there but they are not in one place and are not created by one large team as .NET is. C# is excellent for GUI programming and I doubt there is a better language to use for GUI apps. I also find C# code harder to maintain and harder to read b/c of the lack of headers. Headers have a nice way of quickly showing you what functions are in the impl. In C# you have to close out all the little nodes and then open them up one by one to view all the function impls. I think headers have a purpose and I now understand why C and C++ have them. C# is extremely flexible in that it can make use of any .NET language including C++/CLI and Microsoft has made it so simple to interface between C# and C++ using C++/CLI that you would be crazy to try anything else in a mixed project. I've personally tested interop against non-interop code that utilizes C++/CLI as the 'go-between' and performance was no different than a pure C++ app. Don't ask me how Microsoft got it to be this fast but it is. P/Invoke is a bit slower and more unwieldy as well. Once you know C++/CLI you will only use P/Invoke for Win32 API specific functions you wish to bring into C#. Big downside for C# is that if you want to do advanced GUI programming most of that type of functionality is simply not in .NET and like MFC and Win32 ActiveX controls...most of the controls are quite useless out of the box.
The draw for C++ is that it is extremely fast, extremely flexible, and easier to maintain. Downsides are it can be a bit more cumbersome to develop with b/c it does not hold your hand like C# does and thus also may increase development time. However I'm convinced that a seasoned C++ team could produce a product as fast as a seasoned C# team. Speed of development, in my book, is more related to familiarity with the tech being used than it is with the choice of development language. I can get a pure C++ MFC app up and running just as fast as I can get a C# GUI app up and running. No difference for me at all b/c I'm very familiar with MFC and C#. The argument that C# is faster to develop with is simply not true if all the programmers are familiar with Java or C++ or C. Besides if you are using waterfall or modified waterfall the design of the product should have little to do with how it's implemented in language A or B so the speed of development truly comes down to the speed of design which relies more in the experience of the design team than it does on the experience of those implementing said design.
Citation needed. I would like to cite my own claims by saying the huge amount of vulnerabilities that exist in software like Linux, Apache, Windows or otherwise 'low-level' software written in C/C++ is precisely because memory is not managed and is hence 'unsafe', ripe for exploitation. Go look on phrack.org as an example - how many papers there since the publication of Aleph1 are based on exploitation and security vulnerabilities via the unauthorized control of memory even in the face of code scrutiny and tried-and-true usage?Quote:
I do not decide on managed or unmanaged solely on the fact that managed has garbage collection b/c that is easy enough to program in C/C++.
You say this is 'easy', but I would argue it most certainly is not, and the number of defects and vulnerabilities in software these days written in languages like C/C++ would support that claim I think.
OTOH, there are reasonable ways to combat things like this in C++, where you have a bit more abstraction. Namely you can eliminate a large class of errors if you're using something like shared_ptrs and RAII pretty thoroughly (on that note, exceptions in C++ are mostly a terrible idea IMO unless you do use RAII thoroughly, precisely because exceptions in an unmanaged language like C++ can have some pitfalls when your code isn't designed with exception safety in mind, *especially* when resources like memory are involved, which RAII helps with a lot. Google for example, does not ever use exceptions, to make their C++ more clear, predictable and safe.)
Note that my point isn't that it's impossible to write working, correct software, 'memory safe' language or not. My point is that in a language like C/C++, there is a larger burden on you, the programmer, to make sure of these things, when with other languages, your compiler can just do the work for you.
I would say this is not an argument for headers, this is an argument for a proper module system, something like Standard ML's (where a signature specifies the interface and a module implements it.) Headers/The Preprocessor in C/C++ are notoriously broken in a few ways. Have you ever looked at the headers for the standard C++ libraries, for example? They look like complete ass in every way. Do you know why? Because a simple #define on line 1 before any other #include directives could come through and literally trash everything in the following headers and break things in subtle ways. That's why every identifier in a C++ standard header is chocked with underscores and short, undescriptive variable names, making it look like ass. Essentially, you *cannot* have a standard C++ library with reasonable code in the headers, because the preprocessor can screw everything up.Quote:
I think headers have a purpose and I now understand why C and C++ have them
More to the C# gripe - I don't know why you would have to constantly expand boxes. Are you telling me visual studio doesn't have a simple 'outline' feature to show you what's defined at the top level of a module? I'm almost certain it does, I can't verify right now however (on linux.)
As someone who works on a small team with a ~40,000 loc C++ code base, I'm inclined to believe otherwise, but as you are mainly comparing to C#, I can't really say since I don't use it often or in very large magnitude.Quote:
and easier to maintain.
Really? This is your empirical argument that demonstrates there's no difference? Does it do more than display a simple window and maybe draw a PNG? I'm actually being dead serious here, because this claim is ludicrous unless you have actual statistics and measurements for a realistically sized code base, not some 40 line GUI app anybody can throw together with an API reference.Quote:
I can get a pure C++ MFC app up and running just as fast as I can get a C# GUI app up and running. No difference for me at all b/c I'm very familiar with MFC and C#.
Don't get overly excited. Memory management in C++ is not such a big issue as it was in the past. All the documentation is available, awareness is high as never before and the whole problem is not so prevalent as it used to be. From the cradle C++ newcomers are taught about memory management.Quote:
Originally Posted by Mad_guy
I will agree the burden is on the programmer. But this is necessary. It's a feature of the language, and not something bad at all. I refuse to see Memory Management as a term of comparison between both languages because there is nothing to compare. If we get into that kind of debate than everything goes. And I could say for instance, C# is bad because I can't use it to program my Z80 processor. This type of argument would be however nonsense. And for the exact same reasons as memory management is for C++. It's a feature.
In fact it is easy. Damn easy. So easy that I sometimes get angry at some code I see (and bugs I find on my own code). You see defects and vulnerabilities in today's code however much less than you used to. A lot less. Concerns over security has also been dealt with at the OS level. But do not confuse sloppy code with difficulty in producing correct code. I won't deny more care needs to be taken in C++. But correctly managing memory in C++ is not a difficult task at all. There's very little (if anything at all) that hasn't been put to paper and be made wildly available. There's no excuses. There's just sloppy coders.Quote:
You say this is 'easy', but I would argue it most certainly is not, and the number of defects and vulnerabilities in software these days written in languages like C/C++ would support that claim I think.
C# does lack the ability to separate interface from implementation. This is one big problem when maintaining code. I wish they implemented it as in C++; with headers if needed be. Partial classes in C# help somewhat (actually something I would like to see in C++). But the fact I'm forced to define my class members where I declare them will always be a problem.Quote:
I would say this is not an argument for headers, this is an argument for a proper module system, something like Standard ML's (where a signature specifies the interface and a module implements it.)
This also have a nasty side effect. It doesn't facilitate code reading on any other medium than the IDE itself, as you surely have witnessed already when trying to read from, or publish C# code on the web where a full class is being defined.
Err... What are you talking about? There's nothing wrong with the standard library. Neither you should worry about the standard library. You have no business looking into the standard library. To make the point clearer; it's a library. And its the Standard Library. You don't care about it. You care about the documentation.Quote:
Headers/The Preprocessor in C/C++ are notoriously broken in a few ways. Have you ever looked at the headers for the standard C++ libraries, for example? They look like complete ass in every way. Do you know why? Because a simple #define on line 1 before any other #include directives could come through and literally trash everything in the following headers and break things in subtle ways. That's why every identifier in a C++ standard header is chocked with underscores and short, undescriptive variable names, making it look like ass. Essentially, you *cannot* have a standard C++ library with reasonable code in the headers, because the preprocessor can screw everything up.
The people who designed the standard library are worlds beyond and above mine or yours comprehension of C++. To say the headers look like ass, really makes you look like a fool. Don't. And if it bothers you so much, wraps the standard headers in your own interface. Problem solved.
The Visual Studio IDE is poor in terms of features to support C# more difficult code maintenance. It treats C# as it treated C++ is terms of coder reading features. 2008 introduced some new features. But Code Outline is certainly not what I want. Most people I know cannot adapt to that tool. It's too confusing and it's not configurable.Quote:
More to the C# gripe - I don't know why you would have to constantly expand boxes. Are you telling me visual studio doesn't have a simple 'outline' feature to show you what's defined at the top level of a module? I'm almost certain it does, I can't verify right now however (on linux.)
It was not until we bought the DevExpress suite that includes CodeRush, that we finally started to get some more meaningful tools to help writing and maintaining C# projects. But that's at least 250 USD.
This is the thing that irritates me most about Visual Studio treatment of C#: It forces to spend more money.