This article is for C++ programmers who are (at least for now) not targeting the Microsoft .NET Framework in new or existing applications. It provides some guidelines for moving to the .NET Framework without leaving behind the investment in existing code, and explains why you should consider moving to the .NET Framework not only for new development, but for existing applications as well.
Moving to .NET and WinFX: a Roadmap for C/C++ Applications
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t get it ?. Why should anyone who has already written code in C++ , recompile it for .NET to take a hit at performance and deployability ?.
Versioned dlls were already there for Win32 (.NET’s GAC promises to be another DLL hell, IMHO).
The only thing this ensures is that stack smash bugs become harder to exploit … that’s a good thing – but doesn’t NX do it better and lower down the architecture ?.
Oh, btw – .NET runs without a verifier on local files .. maybe someone should fix that.
“Does this mean you should rewrite all your applications? Of course not.”
I wish Microsoft would have developed a replacement for MFC, using modern C++ techniques, rather than inventing a Java clone. Imagine how powerful a new C++ framework would be if as much effort was put into it as was put into all this .NET stuff!
I also am skeptical about the VB.NET language. Microsoft seems to have forgotten the novice programmer with VB.NET! IMO it is too complicated for the typical VB 6 programmer to understand. There are a few VB programmers where I work and none of them have any interest in learning VB.NET, because it is so different from VB 6.
Its a metaphor, and yes, Microsoft definately is.
The old .NET extensions to C++ were so dreadful (apparently) that MS are throwing them away and coming up with something completely new for their new compiler (VC 2005). Well, this new stuff is better, but still flawed; there is a choice of *FOUR* different destructors to be used depending on circumstances. I’m sorry, but that is a design mess. I believe this shows the new CLI/C++ extensions have deep flaws.
Given MS have thrown away one set of language extensions, why should I believe they won’t do the same again to sort the destructor mess out? I can’t see any good reason to invest effort in writing .NET compatible code … apart from the obvious one involving being paid!