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:
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. :)
I have to say I agree with the point about pretty much any other OO language being easy to pick up if you've battled with C++. It's a very strong reason *not* to keep pushing C++ into problem-spaces better served by more modern OO/component languages such as C#. Limiting the debate to Window's, and further refining to user rather than kernel mode, C++ these days feels more and more like it's use should be constrained to '__C++ {}' (sic) in the same way '__asm {}' was not so long ago.
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.
I strongly disagree that the managed platform is the main difference between C++ and C#, it's the language itself.
Both languages share several keywords, but the meaning is entirely different. Just compare the meaning of struct and class in C++ and C#.
In C++ an enum is implicit casted to an int while in C# it has to be done explicit.
Initialization of static members is different, dispose pattern / using, anonymous methods / outer variables, enumerator / yield etc.
I agree that C++ developers can move to C#, but I don't like the idea to switch between C++ and C# in the same solution back and forth. That's more than likely error prone. I've used C# just for fun so far, so I can't say how many bugs I would make just because I didn't think of the differences between C++ and C#, even if I actually know them.
C++ developers also like their &, * and ^. I also prefer the :: namespace operator over the . because the later one is ambiguous. You can't distinguish object.method(); and class.static_method();
P/Invoke also doesn't work with unmanaged C++ classes. But why do we have to discuss the benefits of C++/CLI here, do you have to push everyone to C#? Does your team try to get rid of additional work?
I also don't agree that C# is a more modern language than C++. There are many things that I like (enum.value for example) and that I would like to see in C++, but then again there will be C++0x "shortly".
-----------------------------
I guess one reason why many have shifted to managed code or want to make the shift is because of all the hype about .NET and WinFX in the past. WinFX was sold to us as the successor of Win32. I've even read articles on major IT sites where the authors claimed to know that unmanaged apps won't run on Vienna anymore.
But then again .NET also has many advantages, the richness of the framework, platform independence to some degree etc.
I also have a totally different question, does it make sense to recompile an x86 MFC application for x64 if the application never ever will use more than 2 GB of memory? I'm not sure if the users can figure out which version they have to download and if there are even any benefits. Would it be possible to put the x86 and x64 code into a single executable with a bootstrapper? Maybe something like PE Compact and then unflat the right code part into memory and execute it? But the main question is, if I don't take advantage of the 64-bit platform, why would I want to ship a 64-bit app?
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
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.
> 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?
Excellent question. This reasoning is exactly why proposals for ordinary PCs to get the .Net Framework, C# language, VB-- language, and C++/CLI were all rejected and Microsoft stayed the course with Visual Studio 6, right?
> Secondly, why is p/invoke a 95% rewrite for you?
It looks to me like that's assuming that 95% of the code will be rewritten from C++ to C#. Now maybe this ought to be easy, for the same reason that rewriting VB6 code in C# is easier than rewriting VB6 code in VB--, but 95% doesn't look surprisingly high to me.
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
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!