|
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.
|
|
|
|
|
Bob Stanneveld wrote:
I'm just a student
You state you can't move on, being a student I'd say change now, you're learning an a soon to be obsolete framework.
My Blog ^
|
|
|
|
|
Holland isn't the innovative country anymore it once was. The government also isn't making things much easier and the universities and colleges here just don't seem to bother that the educational quality is very poor..
They teach us things like: "This is Java, the syntax is almost the same as C and you can use classes... What, libraries you ask? That's beyond the scope of this class" And yes, they still teach us C and no C++.
So moving on on my own is pretty hard to do when I have to spend my time learning 'obsolete' technologies...
norm.net wrote:
a soon to be obsolete framework
MFC won't be obsolete soon, because there is far to much legacy code out there that needs to be maintained... But since I don't wan't to be someone who maintaines software, I guess you are right.
I also got the blogging virus..[^]
|
|
|
|
|
Bob Stanneveld wrote:
because there is far to much legacy code out there that needs to be maintained
True, and in my golden years, I'll be looking for contracts supporting this codebase!
Oh the whole, if you can get yourself a copy of Visual C# Express and VS 2005, then do so, you'll have a wide range of oppertunites waiting for you in the future.
Good luck with your quest.
My Blog ^
|
|
|
|
|
Thanks! 
I've already downloaded all the free express beta's since they're uh,.. free and the might come in handy some time soon. Besides that, the computers these days have way too much storage capacity for the 'normal' home user, so I have to use it..
I also got the blogging virus..[^]
|
|
|
|
|
|
|
CMyForm* f = new CMyForm();
f->Show();
in VC++ unmanaged code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
