Enumerating the advantages of .NET's Managed Extensions for C++ (MC++), Sam Gentile writes:
- Leverages existing investments in C++ programming skills and legacy C++ code.
- Porting unmanaged code to .NET: MC++ allows you to take existing unmanaged code and compile it to managed code (with the /clr compiler switch and IJW ["It Just Works"]).
- Gives the ability to port code at one's own rate rather than re-write all at once.
- Provides the easiest way to add .NET support to your existing native...Windows applications, by allowing you to bridge the gap between the two environments with as little work on your behalf as possible, and with the lowest performance penalty.
Though not a member of the "VB.NOT" 1 contingent, I am dismayed by the above list: Why should C++ developers enjoy such ease of migration to .NET, while VB developers (of whom there are arguably many more) are forced to rewrite their code? I disagree with the opinion that VB is a "dead language" -- there are plenty of apps with limited life spans (say, up to 10 years) for which VB has been and continues to be ideal -- but it would have been nice if Microsoft had demonstrated its commitment to VB by making it as effortless to migrate "Classic" VB code to .NET as it did to migrate C++ code. The message seems clear: If your application is "mission-critical" 2, don't use VB.
1. For the record, several items at this link are misleading or inaccurate.
2. I don't consider most of my apps to merit that description -- I think many developers flatter themselves by believing that their code must live forever -- but there are clearly apps that do. For these, VB would seem to be a questionable choice.
Comments
Posted by Karl E. Peterson on January 15, 2003:
Leave a comment
Your characterization of the list of Visual Fred incompatabilities (footnote #1 above) is uncalled for. I know you feel they are misleading, and taken alone perhaps that is the case, but two points require me to provide clarification.
First and foremost, the list is clearly described as items that will require attention during a migration from Classic VB to VFred. In every case, they represent changed syntax and/or behavior. Granted, some may be trivial, and some may have workarounds. But the mear need for a workaround indicates without question that something is broken.
Second, since the day the list became public, corrections and suggestions have been encouraged. Other than the pathetic response from Microsoft (available in its original form at the bottom of the page), the only mail I’ve received from the community has been with additions to the list. Granted, I never bothered updating it after beta 2, but that’s only because I quit caring about it as a product at that point. If you are, or anyone else is, aware of actual inaccuracies, by all means enlighten us.
That all said, I’d like to extend to you, Phil, my friend, a hearty “Welcome!” Yes, this information has been available now for, well, years. It was highlighted in the Reviewer’s Guide, and continues to attain prominant placement on MSDN (http://msdn.microsoft.com/visualc/productinfo/overview/default.asp), as one of the main reasons to invest in VC++.
Yes, it is infuriating. Microsoft has rendered worthless, in part or in whole, the investments of millions of their customers by not providing a forward migration path for their “data” (code, in this case). Can you even imagine the outcry were they to do the same with Word or Excel files?
But alas, they did protect their own investments, didn’t they? If you or I were to “clean up” VC++ the way they “cleaned-up” VB, Microsoft would become a hardware company overnight. Absolutely appalling.
Microsoft Basic, 1976-2001, R.I.P.