Re: Why C#? CPU independent?
- From: scottelloco@xxxxxxxxx
- Date: Fri, 08 Jun 2007 16:00:55 -0000
On Jun 8, 12:09 am, WoodenMecca
<WoodenMe...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Thank you, guys, you really helped me a lot. I will sit on this issue for a
few more days before I figure things out, but just to think out loud so that
maybe people out there who're with the same problem may benefit a little, let
me write down my thinking process:
I have an MFC application of 72,422 lines of code (yes, I counted, with my
fingers), which was originally ported from Palm OS, I'm going to port it to
WinMo. So a few things worth considering:
1. CPU support. Mine is an off-the-shelf application, theoretically it
should be able to support as many CPUs as possible. In this sense, Compact
Framework/C# is definitely the way to go. But as Scott and Riki pointed out,
there was only StrongARM/XScale in the market in the past four years, so
using CF/C# doesn't really increase my app's compatibility with CPUs.
Although there is still a chance the new and incompatible CPU will come out
in the future, but hey, I'm just a programmer, looking into the future is
really not my thing.
2. Functionality. From my limited understanding about Compact Framework, it
does support some functions/services that are very convenient to use. But my
application does not use Web service or database access (which Microsoft kept
metioning when it comes to why CF), so I guess there is not much in CF that I
can benefit from, or at least it doesn't constitute a compelling reason why I
have to switch to CF. Besides, I'm porting, that means all the code are
already there, the new functionality in CF isn't that important to me either.
4. Flexibility. On the other hand, my app is very UI intensive. It does a
lot of keyboard/mouse handling, custom draw controls, notifications, message
loop tweaking, etc. I'm not sure about CF, but I always hated an added layer
of abstraction on top of system's native API, a.k.a. Rapid Application
Development, such as VB and MFC. They always make things harder when you need
to deal with the intricate side of the system, and RADs are not that rapid at
all in times like these. In all Microsoft's literature about CF, they always
emphasize rapid prototyping, so I believe CF will have the same problem too.
Call me control freak, but I like native APIs because everything is under my
control.
5. Performance. Compact Framework uses intermediate code which means there's
overhead when loading the program up for running. I saw somewhere that some
guy did an AB test using a Tower of Hanoi program. The result was C++ was a
clear winner, I don't remember the numbers, but the difference was quite big.
I know this result may be argumentative and many people may have a lot to
say, but my application involves several tens of thousands of double
precision computation in one operation, I don't want to take the chance.
6. Load time. I read somewhere that some guy said he had a C++ application,
it was fast. One day he added a little code to use Compact Framework to do
Unicode-UTF8 conversion (Don't ask me, I'm just telling you what I saw. This
conversion can easily be done in C++, I don't know why he wanted to use CF.)
Because of this, his program's load time became four seconds. Another Nay
vote for CF/C#.
So, based on above, I'm inclined to vote no for swaitching to CF. (BTW, I
just found out one big surprise, which may be a common sense to many people:
WinMo only supports Unicode. The MFC app I'm porting uses MBCS because it was
from Palm OS, which doesn't support Unicode. So now I'm facing another big
decision: Unicode or no Unicode? :-)
#2 - This sounds correct to me. MFC is supported on PPC/WM so a lot of
your code will port over with minimal changes.
#3 - Agreed. The CF has pretty good UI APIs, but it doesn't give you
the same control as using the native APIs (or even MFC for that
matter.)
#4 - Yes, this could definitely be a problem. Like you said, in a lot
of apps this issue is negligible, but it sounds liek this could be a
real issue in your app. The CF is basically making the equivalent of p/
invoke calls back to native API's (it's more involved than that, but
that's the short answer.)
#5 - This was one of our biggest complaints when we build our first CF
app. The load time for our CF app is at least 3 to 4 times longer than
the load time for our eVC++ MFC app. And the only thing that's really
going at load time in either app is the initialization of the UI.
Yes, it's true that the WinCE only supports Unicode. We had to do the
same thing and move from MBS to Unicode. I was kind of dreading it,
but the switch wasn't actually too bad at all.
.
- References:
- Re: Why C#? CPU independent?
- From: scottelloco
- Re: Why C#? CPU independent?
- From: Riki
- Re: Why C#? CPU independent?
- From: WoodenMecca
- Re: Why C#? CPU independent?
- Prev by Date: Preventing a file to be renamed
- Next by Date: Re: CeAppMgr and Vista
- Previous by thread: Re: Why C#? CPU independent?
- Next by thread: Re: Why C#? CPU independent?
- Index(es):
Relevant Pages
|
