Dr. Dobb's Journal September 2002
The Microsoft name for source code that targets .NET is "managed code." By default, code produced by C#, VB.NET, and JScript.NET is managed, thereby specifically targeting .NET. Code produced by Visual C++.NET, on the other hand, is unmanaged and doesn't necessarily target .NET. To generate managed code with VC++.NET, you must use the /CLR command-line switch.
Likewise, managed data is data allocated/deallocated by the Common Language Runtime's garbage collector. Again, by default C#, VB.NET, and JScript.NET data is managed (although C# data can be marked "unmanaged" via the use of keywords). VC++.NET data, however, is by default unmanaged, even when you use the /CLR switch. The Managed Extensions for C++ — those proprietary Microsoft extensions to Standard C++ that support .NET — let you use the __gc keyword to mark classes as managed so that the garbage collector manages memory for instances of the class. Managed classes have full access to the .NET Framework.
Befitting a language that is powerful and flexible, VC++ can produce both managed and unmanaged code. You can use VC++.NET unmanaged code on non-.NET platforms and in the .NET Framework. Running managed C++ code under the .NET Runtime Execution Engine does offer benefits — access to services for security, memory management, resource management, multilanguage integration, and the like are there for the taking. Unmanaged code doesn't have direct access to these services.
So what would possess you to write unmanaged C++ code in a .NET application? For one thing, unmanaged code usually runs faster than managed code, which suffers from significant overhead. Second, you can incrementally port Standard C++ programs into .NET without rewriting the entire application. In other words, you can use both managed and unmanaged code in the same application, although, again, you'll likely take a performance hit on transitions from one to another.
All in all, this managed stuff sounds okay, assuming you've bought into .NET. Moreover, it is comforting to see Visual C++ pop up on Microsoft's screen, which has been drowning in C# this and CLR that. Gee, if you didn't know better, you'd wonder if Redmond was jettisoning C++ because the language isn't proprietary. From that perspective, Managed Extensions for C++ must look like the next best thing.
No, I don't have a problem with managed code as such; the fly in this ointment is its name — "managed code." For starters, just hearing "managed code" conjures up "managed care," as in the healthcare insurance morass we live (and die) with. Compared to the crimes of managed care, Enron doesn't even register — and that's the guilt by association Microsoft is stuck with every time you hear the name "managed code."
But then, rather than managed code, someone else might hear "mangled code" — source that's hard to read because all comments, blanks, indention, and other readability features have been removed. But that's probably not what Microsoft had in mind either.
Managed code isn't the first time the Microsoft phrase turners tripped over their tongues when trying to be clever with names. Recall that in the throes of its antitrust trial, Microsoft's Bill Gates ushered in the name "trustworthy computing." As you'd expect, it didn't take wags long to counter with "antitrustworthy computing."
And then there's "shared source." Strictly speaking, the only thing "shared" about Microsoft's shared-source policy is the money selected customers share with Microsoft, who in return gives a peek at selected source code in selected software.
Microsoft isn't alone is the name-game game. Back when dot-coms were the rage, cute names came and went in the blink of an i.com, and an entire corporate branding industry emerged to make them up. Hewlett-Packard, for example, reportedly spent more than a million dollars for the nonsensical name "Agilent" when spinning off its instrumentation and measurement division into a separate company. Then there was Scient, Viant, Siara, and on and on.
Of course, the U.S. doesn't have a monopoly on dumb names. For whatever reasons, Britain renamed its venerable Royal Mail service "Consignia." Alas, the experiment failed and the postal service recently returned to the more intuitive name "Royal Mail."
Closer to home, UtiliCorp, a gas and electric utility that started out in 1917 as Green Power and Light, changed its name to Aquila, which is Latin for "eagle." Cute, but hardly intuitive (and you wonder how much that name change cost stockholders). Meanwhile, Aquila recently announced it is laying off hundreds of employees as the company struggles to regain credit and focus.
And therein lies the rub with playing name games — companies lose focus and customers lose confidence. Instead of being clever, companies should be straightforward. If you're an electrical utility, just spit it out. If extensions to a standard are proprietary, then say so without apology. After all, what's more intuitive, in terms of computer programming, than the name "Dr. Dobb's Journal"? It's worked for us.
Jonathan Erickson
editor-in-chief
jerickson@ddj.com