|
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.
|
|
|
|
|
|
I agree. Ugh. Although I have 20 times as much experience with MFC than .NET (10 years vs. 6 months), it's a RELIEF using .NET. Everything is implemented as properties, making it easy to make the system do what you want it to, and all the features you want are there.
I could write PAGES about the problems with MFC, but with .NET I've only found two problems:
1. You can't get the address of a variable in a Watch window. This is useful for observing the variable when it's out of scope of the debugger, and for distinguishing between two or more instances.
2. There's no profiler! The profiler in C++/MFC Version 6 was adequate. .NET only supplies an INTERFACE!
Except for these, .NET is closer to how programming should be done. You type a variable name, and a period, and Intellisense gives you all the class members to choose from. And the .NET classes are rich in functionality; I can almost always find what I need, as opposed to MFC.
(.NET is still only a step closer to perfection. For the perfect programming environment, nothing beats the holodeck on Star Trek. People create complex applications without ever getting an addressing exception or a stack overflow!)
|
|
|
|
|
I've used MFC for a very long time, from the tail end of the MFC 1.0 days and through to the latest version. I love MFC. It made writing Windows applications so much easier and it got rid of the long switch statements for handling Windows messages.
I just don't see a place for it in the modern developers world. Times have moved on and the MFC architecture just isn't flexible enough. We've always had to jump through a lot of hoops to make our MFC apps look and feel like modern applications. (I bet nearly every MFC programmer has a copy of MFC Internals[^] on their bookshelf)
If any Microsoft C++ framework was to continue in the .NET world, I think WTL would have been a nicer choice. It is a lot less bloated than MFC and ATL is much better for COM working than MFC ever was.
MFC has served me well, but now be part of my legacy applications. C# and the BCL suits my development needs so much better.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Here, here!
I don't use MFC anymore, in my last company I started using WTL for smaller projects. It's a shame that Microsoft didn't take on WTL, but thats obviously a marketing decision.
MFC has had it's day now it's time to move on, the .net framework is far surperior, and it looks like it will be here to stay for the next 10 years+.
MFC RIP.
My Blog ^
|
|
|
|
|
Hello,
I'm a C++ programmer and do not use the .NET thechnologies. However, I think that MS should port MFC to .NET since that would make it less hard for me to move on to .NET. One other reason for this is that I think that MS should not force the developers to do it the .NET way since most of the developers have moved on from MFC.
Besides that, using MFC, you can design and program towards a design pattern. I don't know much about .NET, but I don't think that you get much support for design patterns like that.
Just MHO.
I also got the blogging virus..[^]
|
|
|
|
|
Bob Stanneveld wrote:
Besides that, using MFC, you can design and program towards a design pattern. I don't know much about .NET, but I don't think that you get much support for design patterns like that.
Well, it depends on the .NET enabled language. C#, for example, is a great place where design patterns shine (I have written a few articles on the Gamma design patterns illustrated in C#.)
I started my development career in C/C++ (on SCO and Linux and later used both Unix and MS flavors for quite a while,) and though MFC/ATL is great, both are quite cumbersome for modernity in the user interface and enterprise systems. I only "dive deep and native" when needing raw computational power -- and use C#/Java otherwise.
|
|
|
|
|
Bob Stanneveld wrote:
I'm a C++ programmer and do not use the .NET thechnologies. However, I think that MS should port MFC to .NET
If you don't know and haven't used it why do you bother posting an opinion on it?
I voted no, MFC is a complete mess and has been for years, why in the world would we want to bring that crap into the 21 century?
MFC has nothing to do with any design pattern and never has. A design pattern isn't based on any particular user interface technology.
I really don't understand the nerve of people to post opinions on something they don't understand at all, why do you do it?
"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 really don't understand the nerve of people to post opinions on something they don't understand at all, why do you do it?
Why not? We all do it, including you. Everyone has the right to their opinions, and everyone else the right to ignore them.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
PJ Arends wrote:
Why not? We all do it, including you. Everyone has the right to their opinions, and everyone else the right to ignore them.
Of course we all hae the right to make a fool of ourselves, I've excercised that right more than many! 
Few of us, however, do that without basing our opinions on something, most of us don't just spout off without having at least considered what were talking about.
Saying in the same paragraph that you've never used something, have no experience with it then making a pronouncement on it's suitability seems a bit odd don't you think?
"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:
why do you do it?
It may be because I'm just a student who's got his head in the skies. Posting things like that and getting reactions on it puts me and my feet back on this planet.
It may seem wrong to you, but I'm able to learn from this. This is some sort of learning community isn't it? So whay discourage or disapprove it by posting reactions like that!
Besides that, you are a supporter of CP, so why do you want to chase people like me away, instead of supporting the people who make the community so nice? After all, we all have been down there, we cannot move up all by our selves... Or are you the kind of person who feels to good about himself to talk to a person who knows less than you?
Get real and don't read the posts if it makes you angy!
I also got the blogging virus..[^]
|
|
|
|
|
Hi Bob, first off I apologize, I was overly harsh; yes this is a learning community and I would not want to be responsible for hindering that with anyone. You were quite right to call me out on it.
That being said...
I have heard a lot of crap from people over the last couple of years about .net which I feel very strongly about. I think there is absolutely no question it's what the majority of us are going to be programming towards in the not too distant future who develop anything more significant than small utility applications or low level stuff.
I have heard completely wrong-headed stuff from people who are clearly just trying to defend the old ways of doing things for the sake of it without wanting to even consider the possibility that they might want to take an unbiased look at a new tool at their disposal.
I've heard from people who are near evangelical about promoting the .net framework, abandoning a lot of logic and facts in the process.
However I had not heard until now anyone stating they have no knowledge of something, then proceeding to make an argument about it.
I guess I'm a bit old-school in that sense, but I've always felt you learn more by asking than by proclaiming.
Again, I apologize for the harsh manner in which I replied.
"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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
