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.
Posted by Karl E. Peterson on January 15, 2003:
Leave a comment