.NET/C# vs MFC

[wizofaus]

Finally decided I could put it off no longer and tried writing my first
C#/.NET app the other day.
Actually I had already written the app in MFC, so I figured it should
be straightforward enough to convert.
Some interesting results...

a) It took me a long time to get the framework up and going under C#.
This wasn't *just* lack of familiarity with the language/platform, but
the lack of integrated support for the Doc/View architecture that MFC
is built for. It mightn't be the perfect architecture, but it happens
to support a hellavu lot of different types of applications mighty
well, including what I was writing.
I had to dig around to find and download toolkits that others had
written for this, then figure out how to manually plug them in (as
opposed to the MFC app wizard which takes all of 3 seconds to use!).

b) I spent a lot of time having to deal with C#'s "strictness". C++
happily lets you convert between ints and doubles, or use functions
like strtod that will work fine on strings containing "improperly"
terminated numbers, whereas C# won't have a bar of it. Everything has
to be converted explicitly (not necessarily a bad thing, but makes the
code harder to read), and I had to write my own version of strtod to be
able to parse the files my app needed to read. I couldn't see any
options to Convert.ToDouble/Double.Parse that would allow me to handle
strings containing numbers directly followed by non-numeric data. For a
start, I really had to make sure it wouldn't throw exceptions, because
at least in the Debug version, this were horribly slow.

c) All in all, it probably took me three or four times as long to write
the C# version as it did the C++ version. One on hand, not so
surprising, given I'd never used C# before (and only had minimal
familiarity with Java, but I did cut my teeth on VB many years ago).
On the other, most of the time for the C++ version was working out the
algorithms/program logic I needed, whereas for the C# port, this was
already done - and it was great to be able to just copy & paste large
slabs of this straight into C#. I also found myself puzzling over some
very bizarre compiler errors - referring to lines of code that had
nothing significant in them, or errors that didn't logically pertain to
my code at all. But as long as you ignored these and fixed the
problems that did make sense (at which point the other errors
mysteriously vanished), the conversion from C++ to C# was reasonably
straightforward.

d) The really surprising part - the C# *debug* version ran miles faster
than the C++ optimized version! I'm actually 99% sure this is because
the C++ version ran off the standard Windows timer (WM_TIMER), which
severely limited the speed. For the C# version, I just used whatever
Timer component was supplied by .NET with a 1 millisecond interval, and
obviously this was firing far more rapidly than under the C++ version.
Still, I was quite impressed here - although the app was never really
CPU bound in the application logic.

The experience didn't particular leave me feeling there was much
advantage in using C# for the sort of work I do at this point, but it's
obviously a technology that can't be ignored completely. I felt more
comfortable with C# than I did with Java, but given it's closer
relationship to C++ this isn't so surprising.

 

[Richard Grimes]

I had to dig around to find and download toolkits that others had
written for this, then figure out how to manually plug them in (as
opposed to the MFC app wizard which takes all of 3 seconds to use!).

Yup. There was talk at Microsoft 3 or 4 years ago of producing an
application framework for Windows Forms, but it was dropped. I suspect
the reason was Avalon, which has document features built in. I mean, how
could Microsoft persuade people to move to Avalon if they could do that
stuff in WinForms? Yes, call me cynical.

terminated numbers, whereas C# won't have a bar of it. Everything has
to be converted explicitly (not necessarily a bad thing, but makes the

Oh, it is a good thing, believe me

a start, I really had to make sure it wouldn't throw exceptions,
because at least in the Debug version, this were horribly slow.

There really shouldn't be any difference between throwing exceptions in
Release and Debug. All the support for exceptions is there regardless of
whether you use /debug or not. The framework library is a Release build,
but it throws exceptions. Indeed, you *should* throw exceptions in
preference to returning error values.

d) The really surprising part - the C# *debug* version ran miles
faster than the C++ optimized version! I'm actually 99% sure this is
because the C++ version ran off the standard Windows timer
(WM_TIMER), which severely limited the speed. For the C# version, I
just used whatever Timer component was supplied by .NET with a 1
millisecond interval, and obviously this was firing far more rapidly
than under the C++ version. Still, I was quite impressed here -
although the app was never really CPU bound in the application logic.

I am not sure that this is the reason. Think about what is happening in
your C# code. The compiler generates IL, and then at runtime this gets
converted to x86 by the JIT compiler. Guess who wrote the JIT compiler?
People from the C++ compiler team. I view the .NET language compilers as
the front end of native compiler, and the JIT compiler as the back end.
In my tests I compiled some computationally intensive C++ code for
managed C++ and native C++ using various optimizations, and I found that
in most cases (if I ignored the time taken for JIT compilation) the
managed C++ ran quicker. Of course, the EULA says you are not allowed to

The experience didn't particular leave me feeling there was much
advantage in using C# for the sort of work I do at this point, but
it's obviously a technology that can't be ignored completely. I felt
more comfortable with C# than I did with Java, but given it's closer
relationship to C++ this isn't so surprising.

Well, and the fact that much of the framework library is a wrapper
around Win32, and looks very much like it too.

Richard

 

[WRH]

Hello
Its interesting to hear about other programmers experience with
MFC & C#. In my case, just converting a large app from VS 6.0
C++ to 7.0 C++ required numerous changes.

I decided early on not to convert C++ to C#, except for some
specific functions and then I converted the logic rather than line
by line code.

The bottom line for me is now when I develop a new app and I
have a choice I prefer to use C#. I just find it cleaner and simpler
for development.

 

[wizofaus]

Yup. There was talk at Microsoft 3 or 4 years ago of producing an
application framework for Windows Forms, but it was dropped. I suspect
the reason was Avalon, which has document features built in. I mean, how
could Microsoft persuade people to move to Avalon if they could do that
stuff in WinForms? Yes, call me cynical.

I've read some brief technical overviews of Avalon, but does it really
built-in support for everything MFC does for you automatically, no
coding required, including:

* Standard file menu commands (New, Open, Save, Save As)
* Automatic generation of Open file dialog with correct filters etc.
* Tracking document "modified flag", and automatically determining
whether document needs saving
* MRU file list
* Multiple views (windows) all sharing data from a single document
* Choice of handling menu time/toolbar commands at either the document
or view level, depending on what makes the most sense
* Correctly handling menu changes between document types (and the
application when no document is shown)
* Correctly updating the title bar to show the document name first,
followed by the application title
* Automatic registering of file type information in Explorer
* etc. etc.

Even though none of the above is one it's own particularly difficult to
do, and even though I've more than occasionally had to struggle against
MFC in order to customize the behaviour (e.g. correctly remembering the
last directory used for different Open|Save dialogs - instead of
Windows' insane behaviour of remembering it across seemingly all
dialogs in all instances of the application), whenever I've tried
writing a document-based application without MFC I've found myself
having to write the same tedious boilerplate code, which is easy to get
wrong.

Oh, it is a good thing, believe me

I'm not so sure. I can't even remember the last time I was bitten by
automatic numeric type conversions. Occasionally it's been a problem
as far as choosing the correct overload or customer conversion operator
at compile time, but in my code I was reading values as doubles, then
multiplying by a scale factor, and using them as integers to pass to
the Windows GDI functions. I don't see why I should have to explicitly
cast them to int every time. I also tried using floats and then the
float versions of the GDI plus API but that was just as messy (there's
no System.Float for a start!).

There really shouldn't be any difference between throwing exceptions in
Release and Debug. All the support for exceptions is there regardless of
whether you use /debug or not. The framework library is a Release build,
but it throws exceptions. Indeed, you *should* throw exceptions in
preference to returning error values.

I wasn't returning error values - I literally didn't know whether some
lines from the input data contained numbers or not. So I tried parsing
them, and if they failed, I ignored them.
It wasn't an "exception" if they weren't numbers.
But worse, most of the numbers were immediately followed by
alphabetical characters (e.g. 100.0A). In this case, the "A" was the
correct terminator, but try telling System.Convert that.

I am not sure that this is the reason. Think about what is happening in
your C# code. The compiler generates IL, and then at runtime this gets
converted to x86 by the JIT compiler. Guess who wrote the JIT compiler?

Sure, but in this case, I know it was the timer. Taking the timer out
of the equation, the C++ version was slightly faster, but given most of
it's time was executing GDI calls, there's wasn't a big difference.
The C++ version was also definitely much faster loading the document
file in, for a start (this was the one part where any significant CPU
was needed).