لطفا منتظر باشید ...
The Common Language Runtime Is Your Friend
When Microsoft first started showing off its plans for .NET and for the common language runtime, a good many developers from the C++ camp responded with raised eyebrows. All right—so here we are, C++ developers, trained from the beginning to wring the most performance possible from the platform. We also want the greatest control possible. To do that, we manage our own memory, and we can program close to the hardware when we need to. At first glance, the common language runtime looks as though it will rip us from our foundations as C++ developers! That perspective definitely makes sense from the point of view of developers whose eyes are trained on shipping solid, shrink-wrapped-quality applications (either commercially or for the enterprise)— including the modern C++ Windows developer.However, another software development perspective is at play here: that of developers who create software with high churn rates, fast deployment, and constant uptime as the primary objectives. That describes today's Web application market accurately, doesn't it? Modern Web-oriented software is supposed to evolve quickly, be ready to deploy after very short business cycles (a couple months at most), and is supposed to run 24/7. You could create such applications using C++, but perhaps there's a better way. With .NET, the better way is the common language runtime.
Having a runtime execution engine manage your code is a lifestyle that Visual Basic developers have enjoyed for years. We C++ developers often look at the Visual Basic crowd longingly (as they go home on time) or with disdain ("They wouldn't know what real software development is all about"). But think of the advantages a runtime engine gives you. First of all, no lost pointers. Someone else keeps track of them and cleans them up for you. How about misshapen pointers (for example, when you think a pointer is pointing at one kind of structure and it's really pointing to another kind of thing)? Having a runtime manage your code ensures that all pointers are compatible. A managed runtime also gives your code the ability to reflect on itself through the metadata. In C++, you need to use <dynamic_cast>. In the common language runtime, you just call GetType on any object whose type you want to know—a service of System.Object.These types of services are just the ticket for writing quickly evolving software that needs to remain deployed constantly. We tried to write that kind of software for the Web using COM, but COM doesn't quite fit the bill for the reasons we looked at in the previous chapter. One reason is the disparate data typing between COM development environments. Another reason that COM doesn't work completely is because of the involved process of managing components within the system. Finally, if you've ever tried to maintain a Web site using COM components, you know that the Web site must often come down when you want to change components because the DLLs are in use by the Web site. The common language runtime solves all these issues.The advantage we have as C++ developers over the Visual Basic crowd is that while we're perfectly capable of writing common language runtime– compliant code (as we'll see in a minute), we always have the option of dropping down to normal C++ (unmanaged code) at any point for performance or control reasons.The bottom line here is that the common language runtime is your friend, not your enemy—particularly because by writing code to run under the runtime, you can also write code that runs outside the runtime and mix the two freely
