Managed?

Started by
9 comments, last by the Speed Bump 19 years, 8 months ago
Hi, i'm not a native english speaker, so maybe that's why the word just doesnt tell me the meaning of it, but what does the managed mean? Like managed DirectX? How does it differ from the regular DirectX?
Quote:unmanaged C++ to managed C++ or C#
from this thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=264885 So is (C#==managed C++) true? Also in that thread, they say that on some new windows (Longhorn?) a message box will pop up when you launch a program written in c++ saying thats its unsafe to run and can damage your computer, but not if the program is written in C#.(
Quote:at least I had heard, in Longhorn, if you run an unmanaged app, it'll give you a warning box saying that it's an old program and running it could harm your computer.
) How can a program written in C++ be unsafe just becouse its written in c++, and a C# program be safe just becouse its written in C#? So i guess what i want to ask is: 1) What does 'managed' mean? 2) Is C#==managed C++, and in what ways C# would be better than C++ (safer/faster(performance wise))?
"A screen buffer is worth a thousand char's" - me
Advertisement
To answer your first question, here is an extract from an interview of Anders Hejlberg, the creator of C#:
Quote: ROBERT HESS: So maybe we need to take a look and maybe step back and say, okay, when I say Managed Code, what exactly does that mean? Are there like five keys things? Managed Code means it's this, this, this and this?

ANDERS HEJLSBERG: Well, I would say some of the things that it embodies is that you're talking about, physically you're talking about Intermediate Language - or IL - and metadata, packaged in what we call assemblies, which is really sort of a new word for what traditionally was called DLLs. And then you can talk about logically what are the things that Managed Code gives you. And it gives you things like garbage collection, exception handling, structured error handling, type safety, and also object orientation to the core in the system. Before Managed Code, you couldn't really, in between two different programming languages or two running applications, talk about exchanging objects, or one providing an object-oriented API to the other, because the system didn't know about objects. Well Managed Code knows about objects; it is all built out of objects, so to speak. And so objects are first class in the system, and we can therefore build true object-oriented APIs and we can leverage object-oriented concepts like encapsulation and polymorphism and inheritance in building apps, in talking to the OS API.

You actually have to watch the whole interview to make complete sense of it. :-)
You can download the interview here.
Or, just read the transcript, which can be found here.

Managed C++ is C++ compiled for the .Net platform. It runs in an environment that has certain protections that prevent it from mangling your system (e.g. I believe it offers little or no direct hardware access).

Managed C++ is not the same as C#. They have different syntaxes and various semantics, but they compile to the same intermediate bytecode language (MSIL) for bytecode compilation by the .Net environment.

Supposedly, when Longhorn comes out, virtually all code should be managed, so when you run something that isn't managed, the OS will inform the user so they know that such a program has the ability to hang the system or access hardware directly and screw with things.

Performance wise, unmanaged C++ will likely run faster in most cases. However, clock cycles are cheap. People cycles are expensive. The marketing tells us that using managed C++ or C# will speed up development time. People on these boards have had mixed results. I wouldn't ask much more about the comparisons because it will likely turn into a flame war (language pissing match).
So i read the TECHNOBABLE interview/conversation thingie here: http://msdn.microsoft.com/theshow/Episode035/Transcript.html

Here's what i 'learned'(please correct me if i have misunderstood something): programming languages like C++/C/Pascal/... used to compile code to machine language (the native language?), but managed programming languages like the .NET's Managed C++/C#/... compile to IL (Intermediate Language) executables. Which then are compiled to the native language at runtime with a JIT'er (Just-In-Time compiler). So basically the OS knows what the code is about to do(becouse it just compiled it) and can stop it (thus making the executables safe), but that of course has some impact on the performance?
So do i understand correctly what a managed programming language is?
"A screen buffer is worth a thousand char's" - me
Close enough.

You can also compile at install time, which works pretty well.

JIT has, unfortunately, a big limitation in that it can't optimize like a native compiler can. It can optimize better in other areas, but there's no substitution for spending 5-10 minutes doing a thorough code analysis.

Ultimately, Managed code will replace native code when the compile at install technology is up to snuff with native compilers. Combine that with JIT optimization, and you have a solid arguement for kissing C++ goodbye.

I'd give it at least 5 years before that happens, though.

---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.

Eh I still use C++ because it is portable to MAC/Linux.

While I have heard alot about Mono, there is no guarantee that Microsoft will not take action in future, simply because if .NET programs start working on Linux(Free OS), there wont be anything stopping people from switching to linux and yet be able to run all the software which runs on Windows.
Etnu, I disagree. You sound as though you are ignoring the embedded systems market -which is much larger than the PC market. I don't have figures but I think it might be bigger by a factor of 10. Microcontrollers are not going to use JIT code for the forseable future.
GamerSg: There is one thing that would make that difficult. More than a few .NET programs use PInvoke, which is a way to call unmanaged platform-specific code from a managed program. These calls are almost invariably Win32 API calls, which severely limits the portability of these .NET programs.

Additionally, because of the way that WinForms is tied into the Windows message pump and GDI, it takes a lot of work to port WinForms. (Take a look at the completeness of System.Windows.Forms in Mono.) It would be a different story were people using GTk# or managed Qt (I believe such a project is in the works), but those don't come with Microsoft's .NET implementation and so would be ignored by many.

Much of .NET's platform-independance is lip service so that lesser people will think that Microsoft is going nice to developers who do cross-platform or porting work.

Chris 'coldacid' Charabaruk – Programmer, game designer, writer | twitter

Quote:Original post by flangazor
Etnu, I disagree. You sound as though you are ignoring the embedded systems market -which is much larger than the PC market. I don't have figures but I think it might be bigger by a factor of 10. Microcontrollers are not going to use JIT code for the forseable future.


Of course you'll still need languages for embedded programming. No doubt about it. However, as far as desktop and server side goes, it wouldn't be at all unreasonable to expect that managed languages (and, yes, I count Java among them) will become the standard "relatively" soon.

---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.

Quote:Original post by coldacid

Much of .NET's platform-independance is lip service so that lesser people will think that Microsoft is going nice to developers who do cross-platform or porting work.


coldacid, it's not all lip service. Microsoft is already taking the steps to make cross-platform development possible. I'm not talking about Mono. Check out "Rotor".
Jason Olson - Software Developer[ Managed World ]

This topic is closed to new replies.

Advertisement