-3

I'm just wondering what are the really advantages of managed langage over native code

portability: C#/Jave need to have a VM implementation for each plateforms, c++ has to have a compiler

garbage collector: we can have a thread in c++ which check for memory alloc/desaloc

reflexion: maybe we can have a similary mechanism with native code (???)

Today managed code has gain a lot of popularity, however native code has the advantage to be more efficient in general, and lighter ie: there is no VM to have on the target plateform.On the other hand,according to me, the advantage of managed code are not really big, I am wrong ? Is managed code is the good way to follow for the majority of application ?

Guillaume Paris
  • 10,303
  • 14
  • 70
  • 145
  • Yes, you are wrong. If you add the features to a language that is compiled to native code without elaborate runtime, you have basically the same overhead, but lose the JIT cleverness alleviating some of that and have to recompile to get a better implementation. And you still have to get people to install *some* runtime, even if it's smaller. The only difference would be that each executable has 5 MB worth of statically-linked stdlib code instead of the user installing a slightly larger VM once. –  Aug 30 '11 at 19:40
  • probably a better question for programmers.stackexchange.com (if that) – Josh Darnell Aug 30 '11 at 19:41

2 Answers2

2

Your statement about portability:

C#/Jave need to have a VM implementation for each plateforms, c++ has to have a compiler

Is not quite true, or clearly true - C#, VB.NET, Java, etc. need to be compiled once to IL, bytecode, etc. but C++ needs to be compiled to a different version for each platform, which also may require changes in DLLs used (if any) or methods for managing memory.

As for garbage collection, I don't know much about doing that on a thread in C++; but in managed code, you don't have to do any work to have a garbage collector. It's already there. Also, in managed languages you tend to write a lot less code to do what it is you need to do, and that has a huge advantage in clarity. (I find this is especially true when designing the UI of an application.) Also, optimizations can be done in real time using managed code execution, and updates can be made to the engine to make it better.

There are several advantages to both managed and unmanaged code, and in the end, it depends what you're doing. I think big projects are more suited to managed code, and parts that require speed can be done with unmanaged code. After all, unmanaged libraries can be used in managed code and vice-versa.

So, in my opinion, yes, you're wrong. It's a bit of a subjective question, though.

Ry-
  • 218,210
  • 55
  • 464
  • 476
  • subjective question yeah it seems it's the real thing here, I can't get a scientific answer to this question, ty for your opinion – Guillaume Paris Aug 30 '11 at 19:48
1

Managed code is the best way to go for the majority of applications. The reason is that it will be faster for you to implement, simpler for you to unit test and easier to maintain.

There are certainly applications where this is not the case. Applications that must be fast or applications that need special access to the hardware should probably be native apps. Yes you can re-implement the services provided to you in managed applications using native code, but why would you?

Skrymsli
  • 5,173
  • 7
  • 34
  • 36
  • Ease if programming, testing and maintaining is a property of the language (and an arguable and subjective one at that), not of the underlying code. Haskell proponents would claim it beats most popular languages at all tree, yet the most popular implementation of the language is a fully-fledged ahead-of-time compiler spitting out native code. –  Aug 30 '11 at 19:48