|
It's certainly no question of devotion on my part, it's just that 10-15 years of development at my company were based on that and Win32 which equals extreme danger in shifting to a new framework for mission critical apps (in other words, the apps that pay for my sports car!).
Now, we do have a new application that's all .NET here but we have to strap the guy who did it down before he's allowed to talk about the forms designer..
Tim Stubbs
|
|
|
|
|
its funny i happen to be one of those dot not guys surrounding by a bunch of well not really mfc but rather cobol and hardcore g00r00 vbscript jockies.
they fear the framework from what i gather..
change? money? survival of the fitest? who knows .. either way i think we can all agree that .net does have its advantages over its ancestors...
|
|
|
|
|
ancestors? You mean Java 
Tim Stubbs
|
|
|
|
|
I feel the same way about C++ 
|
|
|
|
|
John Cardinal wrote:
I used it for many years and I can only imagine the people most devoted to it are the ones who have a job that depends on their arcane knowledge of something so overly convoluted and complex.
But... VB coders don't care about MFC!  
Heh, yeah, i know what you're saying. While i still do new development with MFC, and maintain a rather large pile of older code, i'll shed no tears at its demise. The move to C# for much new development has drastically reduced the number of "you shouldn't have to know this, but..." questions i answer, not to mention making it much quicker to write and adapt these apps.
It's like having an up-to-date VB, with the added bonus of syntax that doesn't give me flashbacks... 
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Some pro's of MFC versus .NET:
- Startup time for large apps is considerably quicker (since we're not churning away loading countless DLLs from disk..). This is really important for apps starting at logon!
- Memory footprint tends to be considerably smaller (thinking including the runtimes here..)
- The designer in .NET is total rubbish, bugridden and needs to be punished
- Source code. As in, i've got some for the framework as opposed to 'no idea' what .NET is really up to..
- Speed. A contentious issue this but .NET UI-orientated apps feel darn clunky - lethargic compared to an MFC one. And how slow is the debugger?
- Codebase... just a _few_ years more out there..
- Maturity - like it or not MFC is predictable and stable..
- Meglomania. It's my memory, i'll allocate it (and leak it) if i want to.
I think it's easy to get carried away with new shiny microsoft technologies - but it's usually better to sit back, let it mature and settle (version 2.0 for example rejigs tho whole C++ syntax which was SO ferkin horrible in 1.1) before rushing in a porting 10 years worth of work for no appreciable gain. Which is how I see it, as it would take 12 months for us to port out apps to .NET and gain exactly diddly squat (aside from alienating our wives) in return.
It'll be a far more interesting beast with the advent of longhorn.. Of course, our customers PCs will be a lot faster by then too
Don't get me wrong - we are leveraging parts of the framework (Remoting) - but i'd like to see both .NET and it's IDE improve _drastically_
Tim Stubbs
|
|
|
|
|
...people rely on proprietary dependencies such MFC/.NET that will not be supported in the future ?
You *REALLY* want something, fast, efficient, portable and that will be supported for quite a long time ? Then switch all your code in STL/BOOST and use wxWidgets for the UI !
Then you won't have to scratch your head asking yourself how much it will cost you to maintain your software along the ages, without aches I made the switch, read the STL toturials on CodeProject, it's pretty instructive !
Kochise
In Code we trust !
|
|
|
|
|
Not sure if this was meant to be directly relevant to the poll, but if so:
Tim Stubbs wrote:
- Startup time [...] Memory footprint [...] Speed [...]
Adding another layer to a .NET program isn't going to improve that. And if you're writing native code to call from a .NET app, you can already use MFC.
Tim Stubbs wrote:
- The designer in .NET is total rubbish, bugridden and needs to be punished
Which designer? Dialogs/forms? I wouldn't exactly hold up the MFC dialog designer as a model for anything good... most of my MFC dialogs now rely on a code block to control layout, so as to support resizing.
Tim Stubbs wrote:
Codebase... just a _few_ years more out there.
Yeah, i'll agree with that.
Tim Stubbs wrote:
- Meglomania. It's my memory, i'll allocate it (and leak it) if i want to.
Well... Keep in mind, MFC makes liberal use of "temporary objects" to wrap handles and such, by default deleting them during idle processing. It's not full-blown garbage collection, but it does remove a bit of that iron grip you'd normally have on memory management with C++.
Tim Stubbs wrote:
Which is how I see it, as it would take 12 months for us to port out apps to .NET and gain exactly diddly squat (aside from alienating our wives) in return.
Yeah, porting makes no sense at all in most situations. We're having decent luck with doing new app development in C# though, with plans to integrate C++/clr into our main app once that all stabilizes. This has worked well with regards to speeding up development of internal apps, while not wasting resources on the main project.
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Adding another layer? Sorry don't quite follow that one... My point was really that .NET is probably the _least_ relevant tech for lightweight app design.
Designer - forms. And yes, i'd rather use the MFC dialog designer given a choice (and as you say, dynamic resizing isn't that hard..).
Tim Stubbs
|
|
|
|
|
Tim
I was using MFC for over 10 years, the .net framework is where MFC should have tried to go. But lets face it, it never really altered that much over the years since it's release in '91. There are other 'better' frameworks which were far superior - take OWL, I personally would of used it only that there are few jobs in the market place requiring it.
It time to hang up our MFC boots and step into some nice cosy .net boots for the next part of our journey. Notice I've not mentioned C++/C# yet. If you're moving to .net I can strongly recommend C# over managed C++ but hey that just preference. In the long run I can see little or no updates to MFC, which suggests that in the upcoming years the market place will see fewer jobs for MFC. The only way to go is the .net route, Microsoft have invested a hell of a lot of time in creating .net and I'm sure it's not going away.
My Blog ^
|
|
|
|
|
Hey, i'm using .NET now - the gcroot mixed code stuff is actually quite nice - but at the moment i'm only leveraging the more useful bits for our apps. We do have one complete .NET app now and i'm sure we'll continue to add more.
Bring on VS2005 and Longhorn - i think these two releases will make .NET far far more appealing..
Thanks for your comments - i shall give C# a bash (when i get a moment, too much work too little time) as my experience with the current framework and C++ hasn't been too rewarding (it's a kludge atm IMHO)
Tim Stubbs
|
|
|
|
|
norm.net wrote:
the market place will see fewer jobs for MFC.
There has never been a lot of MFC jobs - the market favors Java developers. Anyway, hi norm! It's been a while
Norman Fung
|
|
|
|
|
norm wrote:
hi norm! It's been a while
It certainly has, good we share such a great name ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
My Blog ^
|
|
|
|
|
norm.net wrote:
It certainly has, good we share such a great name
To norm! (all hands on deck raise your glass) 
Norman Fung
|
|
|
|
|
Actually, it is very easy to "port" an MFC application to .NET. Just turn on the /clr switch in your compiler, and the application will compile to IL. Granted, it will still use the Win32 API rather than Windows Forms, but who cares?
The question is: why would anyone port a working MFC application to .NET? Maybe it runs too fast, or consumes too little memory? 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
What the hell kind of computer are you working with? A 386 with 16mb of memory?
Speed and memory are not issues with .net, let's just put that to rest right now. Modern computers come with all the memory needed and I honestly don't see a speed difference and I've developed for years for both MFC and .net.
Maybe if your talking about a tiny little utility application or a game or something, but a large business application bottlenecks much more at things like the sql server, reporting, calculating etc. The application itself isn't a factor whether it's written in .net or MFC.
"In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office."
- Ambrose Bierce
|
|
|
|
|
John Cardinal wrote:
but a large business application bottlenecks much more at things like the sql server, reporting, calculating etc.
That may be the case. But I am not developing "large business applications" and speed and (even more) memory consumption is very important to me. Heck, when I see how .NET code performs on a system with Pentium IV and 2 Gb RAM, it makes me want to cry.
A while ago, our "guru" at the time tried to prototype a machine translation system in C# and found out it was virtually impossible with the way .NET deals with memory. Another coworker had a similar experience with Java.
I had to work with C# as a primary language for a while, and the result was fantastic: it reduced my productivity, but made my programs run slower Thank God, I am back to C++ again (no MFC, though).
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Wow, wierd, everything you are saying is exactly contrary to our own experience here and we were very devoted to MFC years ago as well, but we spent the time to honestly evaluate it with no preconceptions and it just makes sense from all kinds of points that have been talked about to death in the lounge.
I'm not sure how in the world you can say it reduced your productivity, that's actually it's strongest point and the biggest advantage we noticed right away. Of course before we became as familiar as we are now with the .net framework it reduced our productivity, but like anything else, once you learn how to use it, that's not a factor any more.
Oh well, it's a pointless debate, sooner or later you will be forced to use it I reckon.
"In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office."
- Ambrose Bierce
|
|
|
|
|
John Cardinal wrote:
I'm not sure how in the world you can say it reduced your productivity
Simple. For one thing I spend more time writing exception safe code, and in general tracking resources with all this using and finally blocks 
Secondly, .NET class library is a brain-damaged 1980's style OO monster where each class has on average tens of methods. They even introduced My Classes in VS 2005 to help poor VB'ers cope with the sheer size of it, although I can't see how it helps. I can't understand that in 21st century anyone would come up with a design like this.
Thirdly, it is too dynamic in nature. There is a whole class of bugs that in C++ are caught by compiler, while with C# it would compile just fine and then manifest as a run-time exception.
Add to this the fact that there is a lot of available C and C++ code on the net that I can reuse, and be surprised no more
John Cardinal wrote:
Oh well, it's a pointless debate, sooner or later you will be forced to use it I reckon.
No need to "force" me. When it makes sense, I use it. For "business applications" you mentioned, I'll look no further. It just does not make sense for the work I am currently doing and the work I am interested in general.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
For one thing I spend more time writing exception safe code, and in general tracking resources with all this using and finally blocks
Maybe you shouldn't. Exception safe code is unachievable, exceptions can happen and when they do it means the application is broken. Take a SecurityException for instance, do you wrap each method with try / catch for this? If you do you should look into structured exception handling and not blame the framework.
Secondly, .NET class library is a brain-damaged 1980's style OO monster where each class has on average tens of methods.
OO monster? Hey, why even make things OO?? Let's go back into the procedural world!!
Thirdly, it is too dynamic in nature. There is a whole class of bugs that in C++ are caught by compiler, while with C# it would compile just fine and then manifest as a run-time exception.
Such as?
|
|
|
|
|
Anonymous wrote:
Exception safe code is unachievable, exceptions can happen and when they do it means the application is broken.
Dude, I just voted you 5. You think exception safety means "no exceptions". Read this[^] for a starter.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
C# probably can catch all seriuos typos but there is something to be more worried about.
Like: nothing caught at compile time nor at runtime. Division be zero
try this in VB.Net (i presume this is validates as a language)
Sub Do()<br />
Dim iB<br />
Dim iC<br />
<br />
iB = 100<br />
iC = iB / 0<br />
end sub
compiled/runned with the default settings  
With the easyness of using both languages in one project sush things are bound to happen
Damd that ported piece of code
codito ergo sum
|
|
|
|
|
Anonymous wrote:
Secondly, .NET class library is a brain-damaged 1980's style OO monster where each class has on average tens of methods.
Uhm - I don't know what to say here. I suppose it is better to have to deal with a half dozen or so libraries that were never meant to work together than to have a one stop shop for most library needs??? The .NET Framework is the greatest strength of the new Windows API. Of course, it is one huge dependancy.
Anonymous wrote:
Thirdly, it is too dynamic in nature. There is a whole class of bugs that in C++ are caught by compiler, while with C# it would compile just fine and then manifest as a run-time exception.
This runs contrary to almost everything I've found in my 4 years of C# development (and 16 years of C++ development).
About the only area where C# might have a larger runtime error issue is in using printf style string formatting versus iostreams. However, we pretty much have to live with it for multilingual support.
C#, like Java, has been stripped of much of the C language backwards compatibility that makes C++ very difficult to program in well. Plus, C# has an overlying component model that C++ lacks, making it far superior in dealing with application deployment issues.
There are many more examples. However, it is also true that .NET is where all of Microsoft's money has been going for the past 7 years, at least as far as development toools go.
Dale Thompson
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Dale Thompson wrote:
Uhm - I don't know what to say here. I suppose it is better to have to deal with a half dozen or so libraries that were never meant to work together
No, that's not the point. It is that the classes are "fat" among other things. How many members are in , say, ComboBox[^] class? Do you consider it a good design?
Dale Thompson wrote:
Thirdly, it is too dynamic in nature. There is a whole class of bugs that in C++ are caught by compiler, while with C# it would compile just fine and then manifest as a run-time exception.
This runs contrary to almost everything I've found in my 4 years of C# development (and 16 years of C++ development).
Think of this example: How many .NET methods return objects? Whenever you get an object you need to cast it down to use it - if you screw up and cast it to a wrong type is compiler going to complain? Nope. C++ standard library is templatized and each such error would be caught by compiler.
Dale Thompson wrote:
Plus, C# has an overlying component model that C++ lacks, making it far superior in dealing with application deployment issues.
This is one point I agree with you. C++ needs a consistent component/module model badly. Apparently it is being considered for the next round of standardization, but it is a slow process, and it takes even longer to be actually implemented by compiler vendors.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
