TexBlog

Steve Teixeira's Blog -- Thoughts on parallel computing, Microsoft, the industry, and life

Using C++/CLI for .NET development

Using C++/CLI for .NET development

  • Comments 4
Good article on Code Project on some of the advantages of using C++/CLI for .NET development.  The interop performance numbers in particular are pretty remarkable.
 
Let's not be coy about it: if you're writing software that requires significant native-managed interop, you should be using C++/CLI. Period.
  • Oh, please. If I'm writing an app that calls a native library "90% of the time" then my app ought to be written in native c++.

    That article by Nish points out how complex it is to even consider .NET from a C++ program. Why in the world would one even bother with .NET when everything can be done from within C++ without crossing that ugly boundary. Quit trying to justify C++ as a .net language. C# fits that bill well. C++ does not.

    The benchmarks for a native code to native library call are not considered in the article....why?

    It's absurd for you to suggest somehow that we could not function with C++ without using the CLI. Hell the CLI is probably written in C or C++ in the first place. I wouldn't put it past you to start to deprecate direct API function calls and require access to them through some .NET specific mechanism just to force us all into a corner.

    Do us all a favor and quit trying to justify C++ as a "first class CLI language" or endorsing people who do. And don't throw in that crud about me having choices and that I don't have to use it (for now). It's pretty darn clear where all of you (at Redmond) are going with this transition. It's .NET or bust.

    I would love to fork over some more money to Microsoft for a new shiny Visual C++ IDE that has nothing to do with .NET. But, you keep pushing customers like me into a corner with .NET and turning me off to the Visual C++ product. It's sad to watch you, Kate, and Nish working night and day to push this piece of crud upon us and hurt your credibility when all we wanted was Visual C++ 6.0 with some modest improvements.

    If you seriously expect a (C++)programmer to use the CLI when they are calling native libraries 90% of the time, I eagerly anticipate your justification. Please do not respond if all your going to do is pump me full of vague management buzzwords and newly coined phrases (CLI, BCL, and Code Access Security) like Nish does in his article. Also, why does it appear that I cannot just buy Visual C++ 2005 with MFC and ATL(the express editions do not include these. Is there a standalone VC 2005 with this stuff)? Backing people into a corner is not much of a market strategy. Was it not enough that I eagerly handed over hundreds of dollars of my money each year to Microsoft. Was that too easy so you decided you might as well piss off those customers who routinely gave you fairly large chunks of revenue?

    If you don't want my easy money then I guess you'll now have to fight for it and justify it. You gave up on Visual C++ 2003 CLR type programming so would it have been that hard to blow off the dust from Visual C++ 6.0, include the new rewritten functions for security's sake, the few improvements needed to MFC, a few new icons here and there, and collected a few hundred dollars a head every two or so years from the members of eagerly awaiting Visual C++ community? No, you chose to alienate us then later try to convince us that you were trustworthy members of the C++ community. Give us a break. You could obviously care less about what we want and you obviously have marketed your Visual Studio product line to everybody outside the VC++ group.
  • Hi Bob,

    I hope you don't think I'm suggesting that C++ developers must use .NET. If you don't see value in .NET for the kind of software you write, then I would encourage you to stick to native development.

    .NET has some great benefits, but it also carries with it today some performance and working set trade offs. For some kinds of VC++ applications, the benefits of .NET are not worth the cost, and that's okay. It's our job to A) Make .NET so compelling that it's worth the trade-offs, B) Make .NET so efficient that the trade-offs are inconsequential, or C) some combination thereof.

    Native Win32 development still works great today and it will continue to work well in Windows Vista (Longhorn). Yes, it's certainly possible that someday WinFX will supplant Win32 as the primary API for Windows, but that's not going to happen anytime soon. We're years away from even having that conversation.

    The point of my blog entry was this: if you need to do both native and managed in one application, then C++/CLI is the best way to do that.

    Your point about the VC6 IDE is well taken. We recognize that the VS 2002 and 2003 IDEs were not necessarily considered a step forward in all cases for VC++ developers. In fact, the IDE was a flat step backward in some circumstances. We're worked hard to fix that in VS 2005. If you do get around to trying VS 2005, please let me know how you think it stacks up to VC6.
  • Steve - Thanks for linking to my article, I was a little surprised when the view-count jumped up sharply a few days ago till someone pointed out that I got linked from here :-)

    Bob - I was not comparing C++/CLI with Native C++ - the comparison/analysis was between C++/CLI and other CLI languages. The article assumes that the developer is using .NET either partially or totally!
  • Nishant,
    Always a pleasure to link to good C++ articles! :)
Page 1 of 1 (4 items)