Dela via

C++/CLI and Compact Framework: additional clarity

  • Artikel

Based on the comments to my last blog post, I think I need to provide a little more clarity and context to get the feedback I'm looking for.  Reader Vyacheslav touched on most of the points, so let me clarify by addressing the issues he raises...

First is the code reuse. There is a need to use .Net types from within "legacy" code.

Yes, code reuse is certainly the big need here.  However, what I want to understand is the specific scenarios around code reuse.  For example, existing C/C++ code can be reused today in .NET CF scenarios by p/invoking from C#.  I'd like to better understand why this solution doesn't work well for you.

If we look at how we accomplish C++ reuse on the PC-side of things, there are two additional flavors to consider:

  1. Mixed mode.  You can compile some modules with the "/clr" switch, and the compiler will use IJW interop to automatically thunk between native and managed code.  This is a great solution because the runtime characteristics of the existing code do not change, but you do have to design carefully because the native-managed transitions are not free and can add up.
  2. Pure mode.  Existing C++ code can be compiled to MSIL using the "/clr:pure" switch, yielding code that is pure .NET MSIL code, but it's not safe, verifiable code.  This approach means you don't pay the price for native-manage context switching, but it does have the annoying habit of changing the runtime characteristics (e.g., performance) of your existing code since your existing code is no longer being executed as native code.

Focusing back on .NET CF, I want to point out that option 1 is not supported by the Compact Framework today; there is no IJW in .NET CF.  Perhaps it's possible that the .NET CF and VC++ teams can collaborate on building out this technology some time in the future, but it is a substantial amount of work.  Option 2 is probably less work, since the .NET CF does support unsafe code today, but I know from experience that it doesn't always provide enough runtime fidelity as compared to pure native code to meet folks' needs.

So, back to my question: in which of these two scenarios is it more important to reuse existing code with .NET CF? Or do you think both are required for your success? Or are there other reuse scenarios I'm not considering?

Second is inability to migrate to managed world instantly because of a large investment in the existing code and a lack of free resources. Currently there is no migration path but complete rewrite. p/invoke will save maybe 5% of our code.

This comment raises two questions in my head.  First, why are you trying to get to the managed world? What are the benefits of this code running in the managed world that you aren't able to realize with the code running in the native world?  Secondly, why is p/invoke a 95% rewrite for you? That's a surprisingly high figure.

Third is that with C++/CLI you can easily use code written by C++ devs which are not aware of .Net existence. No learning curve for them at all.

Okay, apologies in advance for being outright controversial here, but I have talked to a lot of customers, and I've yet to talk to a single customer that has been unsuccessful in getting their C++ developers to be productive with C# in a very short period of time.  C++ developers already use arguably the most gnarly mainstream programming language, which tends to make it easier for them (as compared to other kinds of programmers) to pick up new languages quickly.  I would argue that the majority of the learning curve here is about the managed code platform, not the programming language you're using to talk to the platform.  This is the learning curve you need to traverse no matter what language you choose for .NET CF.  Of course, this is just one guy's view, so I'd love to hear other views.  :)

Comments

  • Anonymous
    November 03, 2006
    The comment has been removed
  • Anonymous
    November 03, 2006
    I don't think there is a clear-cut, compelling argument for C++/CLI on .NET CF. But I do think there are a number of smaller benefits that, when considered together, seem to call for support.
  1. C++/CLI can bring more performance to managed apps. Therefore, developers concerned about performance are not necessarily forced down the native code path. Performance is almost always a stronger consideration in mobile apps than desktop due to the slower processor and less RAM.
  2. C++/CLI in an elegant way to bring legacy C++ code forward to a managed environment; p/invoke, and the need to expose your C++ code as DLLs is not. In addition, the DLL interface is not anywhere as rich as being able to freely mix old and new code together.
  3. Language choice is important, and while it is true that any C++ dev can do C#, the question is, do they want to? There may be the question of preference, or there may be the issue of existing utility tools that are C++-only, e.g., code generators. You will be more successful if you let your customers choose their language, period. There are probably other "smaller" reasons - I hope Microsoft decides to make C++/CLI on .NET CF work.

  • Anonymous
    November 03, 2006
    The comment has been removed

  • Anonymous
    November 03, 2006
    Are there any plans for C++/CLI support for the .NET Micro Framework? I find it a bit odd that on the official MF site they claim that C# is 4 times as productive as C++. http://www.aboutnetmf.com/entry.asp

  • Anonymous
    November 03, 2006
    To Andre, you have made the case that C++ is different than C#, but not better. Regarding the productivity difference, my team found a 30-40% productivity increase switching from Borland C++Builder to Visual Studio 2005 and C#. It's not exactly 4:1 (I don't personally believe that is typical), but I think most shops will see the kinds of gain that we saw.

  • Anonymous
    November 05, 2006
    The comment has been removed

  • Anonymous
    December 06, 2006
    I have the task to port a C client library DLL to Windows CE. This contains stucts, marshalling to UTF-8, callback function pointers etc. This is a really burdon task with P/Invoke, and it ends up to support C# only (and not .net). With a tiny managed C++ wrapper i got to run it on my Windows XP quite quickly (now supporting .net languages), but now i found out that i can't reuse this wrapper on CE (CF) and i need to start again from the beginning. It is a real pain to notice that days of work are lost. The documentation is not clear about all this and i had to learn it the painful way (try and error, scan news groups etc etc). Going now back to P/Invoke what more hazzles and incompatibilities will follow? So i definitely vote for C++/CLI support in CE to have the same development environment all over, instead of maintaining different ports on different Windozes, regards Marcel

  • Anonymous
    January 04, 2007
    To expect a pInvoke call to solve all the interop problems in the  Compact Framework is almost mind numbing. Many of us have valuable code that dates back almost 20 years with some fairly complicated business logic and architecture, with many of us and you response to us is "dude just pInvoke".We are telling you that pInvoke does not solve our problems, for some reason you refuse to believe it. C++ needs to be a first class citizen in the .NET world, Herb Sutter understands our point, he works there, tell him to go pInvoke and see what he says!