|
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
|
|
|
|
|
Hello,
I accept your apology.
I also should have looked for more information before I posted that message. I shouldn't have called MFC a design pattern since it's a library that supports an architecture.
I must confess that I alos said a lot of dumb things about .NET. I had one bad experiance with C# and some other people working with me on a project. It were their bad programming practices and my bad leadership that almost cost us 6 months of work, not the tool we were using.
That project was also the reason for my post. The bad programming practices of my fellow students led me to believe that .NET was good for nothing and that you had to do everything yourself. But the more I think about MS betting the future of the company on .NET, it should at least be worth to take a much deeper look at...
I also got the blogging virus..[^]
|
|
|
|
|
I think it boils down to using the right tool for the right job - and in that scheme of things MFC/WTL etc have a firm place, in that you can produce fast apps with small overheads whereas with .NET it's not really achievable (YET - perhaps with longhorn that will change considerably). On the other hand .NET is GOOD at web development, visual basic has finally become something slighty less silly and exposes new technologies (like remoting) which are pretty useful.
I'm waiting for version 2.0 with proper c++ support, holding out for a better (more stable, less buggy) IDE etc..
Tim Stubbs
|
|
|
|
|
This all assumes that a .net app is slower to the point of making a difference and larger which isn't true.
People keep saying this, but it's just not an issue again unless you're developing device drivers or low level stuff. .Net apps are plenty fast on any modern computer, indistinguishably fast in most cases from an MFC app of similar size.
And in ter4ms of mfc apps being smaller, this just isn't true. Exactly the opposite is true, I gurantee you I can write just about any app of similar functionality that will take up less disk space than the same MFC app. That's what amazed me about .net when I first started with it, a complete working application in just a few k.
The .net framework is larger, sure, but it's a standard component of windows from here on out, and speaking as a developer that has had to distribute mfc apps over the internet and include all the dozens of dependancy .dll's to ensure people had them on their computer, there is no question .net wins in the size department hands down, not even close.
"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
|
|
|
|
|
Slower - sorry but i disagree heartily. Real world examples? Crap Cleaner Versus Erase Temp (both are designed to run at startup... guess which churns your drive more!), Norton Ghost 9 (spit) versus True Image 8. If I'm writing a startup app, a service or some other thing designed to be running in the background and NOT hogging your memory/cpu then i wouldn't make .NET my first choice. And in extreme - not MFC either!
Whilst i sit here, drumming my fingers for .NET to load all it's dependancies from the assembly, compile the code etc etc MFC has already been running for some time..
And yes of course it takes up less space - so long as we don't count the 20mb odd of bloated runtime we have to distribute with our apps (and WE do with our .NET applications) and then do it all over again for the next .NET runtime. I've got one installed now - 1.0 and in the near future i'll have another - 2.0. MFC doesn't have 'dozens' of dependancy DLLS (you REALLY want to talk about number of DLLS? <grin>) in any case (what on earth are you distributing anyway?). In either system, you either rely on the framework being there (thus making your download/distrib smaller) or supply it with (which most people prefer). Sadly our customers machines don't get all the latest updates applied (I read that SP2 is still rare in corporate pcs - eeek!) so we have to supply, out the box, all the stuff to get it working. Our MFC distribution is therefore much, much smaller.. As for being a 'standard component' - of which service pack? It's an optional download from windows update as i remember..
.NET isn't quite the second coming of christ some would have us all believe. I believe it has it's place, some great technologies as well as some major shortcomings (heresy! stone him!) in _practical_ end user experience that people overlook, as well as being pretty rubbish in some areas ( if (C++ syntax == joke) wait for version == 2.0) for us developers. MFC isn't anywhere near perfect either, but, like .NET it has it's uses.
I, thankfully, am not alone:
http://west-wind.com/weblog/posts/1695.aspx
BTW if you really want to suffer, try running compact .NET apps versus MFC ones on Windows Mobile 
Tim Stubbs
|
|
|
|
|
Tim Stubbs wrote:
Whilst i sit here, drumming my fingers for .NET to load all it's dependancies from the assembly, compile the code etc etc MFC has already been running for some time..
Holy cow you have a slow computer. Sure this is an issue with older hardware, but .net is in it's infancy and the curve is just right as I see it. On my system there is just no discernable delay loading the framework the initial time and of course no delay at all on subsequent runnings of .net apps.
Tim Stubbs wrote:
so long as we don't count the 20mb odd of bloated runtime we have to distribute with our apps
Why in the world would you distribute them? They are part of windows update - just point the users at the windows update site if required, but the fact is that it's increasingly less likely that the user doesn't already have it. Just for one example, anyone with a modern ATI graphics card already has the .net framework installed.
Tim Stubbs wrote:
MFC doesn't have 'dozens' of dependancy DLLS (you REALLY want to talk about number of DLLS? ) in any case (what on earth are you distributing anyway?).
We *were* distributing Crystal Reports runtime and all it's megabytes of requirements, MFC based 3rd party components that required lot's of specific .dll files beyond mfcXX.dll, the windows installer etc etc. It all adds up. The same app re-written in .net using a .net reporting engine and .net 3rd party components and runnable right off the bat with no installation requires exactly nothing to be on the users computer other than the framework itself. That's my point, anything related to MFC in a REAL WORLD APPLICATION requires many megabytes of accompanying files, the same app in .net is microscopic in comparison and that's even if we include the framework in some cases.
I think this argument always boils down to people who write larger business oriented apps and have done so for years being completely convinced of the benefits and superiority of the .net framework and on the other side lot's of people who seem to care more about size and speed versus the fact that in the end there is a user who want's to get some work done and couldn't give a crap about anything but how many features are there and how quickly those features will allow that user to accomplish the tasks they need to.
It could be argued that a really superior app would be written in assembly and run from the command prompt because it's so tiny and fast, but that's not the issue in the real world outside of the real of device drivers and low level stuff.
The central consideration should always be the end user, not what *we* think is best from our point of view but what's best from their point of view. If, with .net I can add quickly and easily with no worries about memory allocation etc 50 more features in a tenth of the time that are exactly what the user is requesting, it's .net hands down no question.
I've written an app for .net compact for the CodeProject .net compact contest and my conclusion was that .net compact framework sucks completely I agree.  It's painfully hard to get anything of substance done with it which is why there are so many 3rd party enhancements that basically just interop to windows code. Microsoft has a long way to go on that score.
"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 think this argument always boils down to people who write larger business oriented apps and have done so for years being completely convinced of the benefits and superiority of the .net framework and on the other side lot's of people who seem to care more about size and speed
I think you nailed it down. If you develop business software either in-house or for a known client, you'll pick the tools that are best suited for that particular task. I only wonder why you have ever used C++ and MFC for such applications. VB is usually better for that purpose (for exactly the same reason as .NET), or if you really can't stand VB, Delphi is a great RAD tool. Heck, even Java is better than C++ for such applications, although not much.
However, there *are* developers who are not in this niche, and they may just need different tools. Since some of the libraries I work on end up being sold on the open market, I must not assume that the end-user has any framework installed, and I must make sure it runs at least as fast as the competition, and I must not allow my code to consume 90% of available RAM before GC kicks in. Does it make sense?
And now, let's burry the axes, and go for a ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Java wasn't even around when we started, VB was vastly unstable and a long way from being OO.
Shrugs..
Tim Stubbs
|
|
|
|
|
Slow computer - our customers do not typically have bleeding edge equipment and most corporates are on a 3-4 year cycle...
ATI card - check. Uses .NET - nope I elected to download the non-.NET version (you do know that you don't need to run the fat command centre, right?) thanks! 32.6 mb of download versus 24.6...
Microsoft provide the runtimes so that you _can_ distribute them - and what's the problem in doing so? A CD contains 700mb of data, a DVD gigs - unless you're providing software for download it's actually quite nice to have your installer put the damn thing on there for them. What's the cost to you?
Ah, so you're argument was based on distributing another 3rd party set, seperate from MFC.. er.. ok I guess you're alluding to that fact you can do more in .NET 'out the box' but i'd sure hope so, given the size of the damn thing! Again, this has no bearing on my point - that .NET and MFC suit quite different needs. If i was to write 'larger' business orientated apps - say, a web based banking system to run globally on a server farm - would i choose MFC? Er, no
You're continuing to flail around the point, rather than seeing it - I actually, for the most part, agree with you. .NET is undoubtably the future for development under windows, but it *isn't* the be all and end all for all apps *right now* - and - guess what - neither's MFC. I've given solid examples of apps where .NET doesn't work well, as well as a whole platform (window mobile) where it sucks ass big time.
Relax - my only act of heresy was to declare .NET not perfect, I shall say my hail mary's later this evening..
Tim Stubbs
|
|
|
|
|
AND..we need to wait to see which way the tail (MS) is going to wag the dog (us) next. Personally, after reading Dr. Grimes message I think we need to see what MS is doing with .net before wholesale rewriting anything or even retooling.
One of the apps at work was developed with .net (mostly vb.net I believe) and it takes nearly 20 seconds to load. I'm running a 1ghz machine with a gig of ram. Not totaly state of the art but no slouch and sorry but the performance does not compare to MFC or other C++ application.
Don't get me wrong...I really like .net for web apps and the desktop apps I use at a home based business where I don't have to give them to anyone and it takes a short time to get it up and running. Just can't make the customer download the runtime. Home machine is state of the art but I still see the lag in managed applications vs. C++ applications. And I just can't bring myself to forcing a user use a .net app on the client yet.
For me.... .net on the client is just not ready for prime time!
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
