C++, Borland, WTL, .NET etc. etc.
-
I still have not decided to move to MFC 7 as a public display of my disapproval to the lack of interest paid by MS to MFC. I am sure this post will grant me a personnalised letter from Bill G! Your point re virtual functions: I have been there many times... having to copy and paste lots of MFC code because one simple function was not virtual! A nightmare! But the main anti MFC people's point (the ones that preferred C with switch case, I am talking circa 1994) is the fact that virtual functions are an additional weight to the big Windows machinery. And defining everything virtual would be overkill. It would be worth doing it (making almost everything virtual) and see if it makes a difference in performance!
>I still have not decided to move to MFC 7 Good call. Not worth it unless you are dead-set on using one compiler/IDE for all your projects. I had lots of grief when I tried to port some large MFC42 apps to MFC7 - gave u in the end and have stuck with using two IDEs/frameworks - MSVC6/MFC42 for my legacy apps and VS.2003/WTL/ATL7 for all my new stuff.
-
If MS have any sense they will base any new unmanaged C++ framework on WTL - Borland couldn't compete back when they were a powerful player - remember OWL? - so they sure as hell won't be able to pull it off now. I always remember OWL vs MFC being like Betamax vs VHS - OWL (Betamax) was a more elegant framework, but MFC (VHS) had a lot more users and a lot more support behind it. Back in 1993, I asked my boss which framework I should start using as I was switching to C++ and he told me MFC was the way to go because Borland would eventuall lose the Windows C++ development war. He was right. As for MFC. Well, personally I don't care if MS never do anything more with it - I am happy for them to kill it off - as it won't make any difference to me in the slightest. I have two extremely large MFC apps that I still maintian/devlelop, but they use MFC42/MSVC6, both of which are already yesterdays news. MFC7 hardly added much functionality - all it did was create me a load of problems when I attempted to port my apps (so I could stick to one compiler using VS.200x). So I won't ever be using MFC7. Period. MFC served its purpose, and I think MS will continue to support it (i.e. the odd MSDN article and MFC7 service pack) but as my new apps are written using WTL, I don't care about MFC anymore. If I was a fresh-faced noob who wanted to write Windows apps using unmanaged C++ then I would go for WTL. It is probably easier to get to grips with if you haven't ever used MFC (and hence you have some mental "baggage")- and being template based, is for more elegant and extensible than MFC. I find it a joy to use - there is a learning curve, like anything, but I can hinestly say I am as productive now in WTL as I ever have been in MFC (lack of WTL ClassWizards aside!). Coupled with ATL7 it is hard to beat (and let's not forget that WTL is build on top of ATL - and ATL is very much a supported MS product - ATL7 added lots of new functionality). MS are currently scratching their heads over WTL as it getting more and more popular - a real conundrum for them to be honest. Do they give it their full support, enhance it and potentially distract people from .NET or do they leave it as is? Without "proper" support, many people won't want to use it - or many peoples bosses won't want them to anyway - and without this magic support, WTL will never be as popular as MFC was in its heyday. It needs a few decent books (Mr Dunn!), it needs some MSDN articles in order for many people to feel comfortable using it. Personally,
WTL for president
-
Please somebody tell me what's so wrong with MFC so everybody would want to bury it... I do understand the need for .NET for web development (if one does not want to go the java way), but for Win32, it does the trick. Of course, MFC is not lightweight but who cares about a few more hundreds of Ks in an application? Oh and the real reason for my ranting... am I the only one with zillions of lines of legacy code and hence very scared of the announced death of MFC?
I'm not an expert on MFC, but I do remember that my week of playing with it ended with me running out of the house onto the street, naked and screaming armageddon with curlers in my hair. I think I made the mistake of having started out using raw Win32. I found MFC very frustrating. I read somewhere that MFC came about very quickly as a reaction to Borlands OWL having gained popularity, and as such it wasn't well designed from the start. In any case, I love WTL so what do I know? What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
BadJerry wrote: am I the only one with zillions of lines of legacy code and hence very scared of the announced death of MFC MFC can't die. Whilst there is a Win32 API there will always be an MFC. True, Microsoft won't probably be adding any new classes or fixing any more bugs. MFC is the COBOL of the 21st century... all the upstart young programmers think it is out of date but there is so much legacy code that all the wishes in the world won't make it go away. I've been using MFC since 1993. I still use it for 80% of my work because I can't afford to throw away 10 years worth of code and experience. It may be old but it does the job it was designed for, Windows Desktop applications. It might not fit in the new WebApp world but then it doesn't need to. Michael 'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
Michael P Butler wrote: Whilst there is a Win32 API there will always be an MFC. I wouldn't be so sure there will always be a Win32 API. For future OSes, I've heard that Microsoft is going to try to cut down the API, or make it only accessable through managed code/calls. If your nose runs and your feet smell, then you're built upside down.
-
A few posts down there is a link to a very interesting article on C++ and additions to the language. That got me thinking, on the future of C++ and application development. :confused: Although .NET is quite good (I really like C#, and APS.NET seems very nice as well), I feel that in the next few years there will still be a (big? :confused: ) need for 'unmanaged' code, especially C++. This for a number of reasons. Although .NET and JITers can be competitive when it comes to speed and such, there are (and will be) programs which would need C++ for optimal performance. Further, some people/companies are very skeptic on the whole MSIL and reverse engineering part. Because of this, and more, I think that unmanaged code, not only on Windows but other platforms as well, wil be in demand for quite som time. Only problem is that we need a "modern" application framework for this. The present choices do suffice at the moment, but are generally frowned upon. Especially when comparing them with modern products like .NET Framework etc. Some time ago (last month actually), Borland announced that they are in the process of developing a modern and Standard compliant croos-platform C++ RAD API product. Open Letter. When I read this, I thought GREAT. But then again, the last couple of years Borland has begun to fade away - so I'm not so sure if they can pull it off. I sure hope so. On the other 'side' there's MS. They still have MFC - and although I'm very green when it comes to MFC (I'm still learning it actually) I can safely say that it's not modern. They do have WTL though which seems really promising. At one of the microsoft.public newsgroups a guy from the MS VC++ compiler team said something to the extent of MS being surprised by WTL's big popularity, and maybe it'll be the basis for a new unmanaged C++ framework. :omg: So what about all this? Is the .NET MSIL reverse engineering threat exaggerated? Can the Borland adventure bring something good? Or should MS focus more on WTL as the future unmanged C++ framework? Or is all this irrelevant in the coming .NET future (if there is one)? Aynway, just me ranting probably...;P;P PS.: Sorry if this is not "Lounge material". But I didn't know where else to put it....:rolleyes::rolleyes:
I'll be happy to see MFC go. I never really liked it.. I only used it because the VC6 wizards support it well... or to maintain legacy code... or to write quicky throw-away code. MFC seemed to get worse in VS.NET (e.g., adding unnecessary dependencies on DLLs that aren't redistributable), so I've stopped using it. I've never used WTL, although a lot people here seem to like it... I tend towards either writing straight standard C++ or Win32 API code for non-GUI apps, and for GUI apps I use something like wxWindows. As for the .NET future, I think it too will take a while to really get going, right now it seems to be doing well in the web server arena - but nowhere else. I have never even seen a desktop .NET app. Getting the .NET runtime (and the right version of it) onto users' systems is a huge issue. If your nose runs and your feet smell, then you're built upside down.
-
If MS have any sense they will base any new unmanaged C++ framework on WTL - Borland couldn't compete back when they were a powerful player - remember OWL? - so they sure as hell won't be able to pull it off now. I always remember OWL vs MFC being like Betamax vs VHS - OWL (Betamax) was a more elegant framework, but MFC (VHS) had a lot more users and a lot more support behind it. Back in 1993, I asked my boss which framework I should start using as I was switching to C++ and he told me MFC was the way to go because Borland would eventuall lose the Windows C++ development war. He was right. As for MFC. Well, personally I don't care if MS never do anything more with it - I am happy for them to kill it off - as it won't make any difference to me in the slightest. I have two extremely large MFC apps that I still maintian/devlelop, but they use MFC42/MSVC6, both of which are already yesterdays news. MFC7 hardly added much functionality - all it did was create me a load of problems when I attempted to port my apps (so I could stick to one compiler using VS.200x). So I won't ever be using MFC7. Period. MFC served its purpose, and I think MS will continue to support it (i.e. the odd MSDN article and MFC7 service pack) but as my new apps are written using WTL, I don't care about MFC anymore. If I was a fresh-faced noob who wanted to write Windows apps using unmanaged C++ then I would go for WTL. It is probably easier to get to grips with if you haven't ever used MFC (and hence you have some mental "baggage")- and being template based, is for more elegant and extensible than MFC. I find it a joy to use - there is a learning curve, like anything, but I can hinestly say I am as productive now in WTL as I ever have been in MFC (lack of WTL ClassWizards aside!). Coupled with ATL7 it is hard to beat (and let's not forget that WTL is build on top of ATL - and ATL is very much a supported MS product - ATL7 added lots of new functionality). MS are currently scratching their heads over WTL as it getting more and more popular - a real conundrum for them to be honest. Do they give it their full support, enhance it and potentially distract people from .NET or do they leave it as is? Without "proper" support, many people won't want to use it - or many peoples bosses won't want them to anyway - and without this magic support, WTL will never be as popular as MFC was in its heyday. It needs a few decent books (Mr Dunn!), it needs some MSDN articles in order for many people to feel comfortable using it. Personally,
Robert Edward Caldecott wrote: MS are currently scratching their heads over WTL as it getting more and more popular - a real conundrum for them to be honest I'm not sure, WTL and .NET would server two completely different purposes IMO. Robert Edward Caldecott wrote: It needs a few decent books (Mr Dunn!), Damn, I'd sleep outside the bookstore like a groupie. Are you listening Mr Dunn??? Like a GROUPIE!! What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
I still have not decided to move to MFC 7 as a public display of my disapproval to the lack of interest paid by MS to MFC. I am sure this post will grant me a personnalised letter from Bill G! Your point re virtual functions: I have been there many times... having to copy and paste lots of MFC code because one simple function was not virtual! A nightmare! But the main anti MFC people's point (the ones that preferred C with switch case, I am talking circa 1994) is the fact that virtual functions are an additional weight to the big Windows machinery. And defining everything virtual would be overkill. It would be worth doing it (making almost everything virtual) and see if it makes a difference in performance!
It's not worth the public display, but there are other valid reasons (bugs not fixed, new bugs, ide sucks, etc etc). As for virtual functions, the C goons are correct in that OVERUSE of virtual functions can slow a program down (double-indirection problem). But since the runtime for the dot-net classes are 11megs+, the overhead seems VERY small to me. But hey, I just code real-world stuff, I'm not a pHD, what the hell do I know...
Todd C. Wilson (meme@nopcode.com) NOPcode.com "Flow with whatever may happen and let your mind be free: Stay centered by accepting whatever you are doing. This is the Way." - Chuang-Tzu "Zen in the Martial Arts"
-
Robert Edward Caldecott wrote: MS are currently scratching their heads over WTL as it getting more and more popular - a real conundrum for them to be honest I'm not sure, WTL and .NET would server two completely different purposes IMO. Robert Edward Caldecott wrote: It needs a few decent books (Mr Dunn!), Damn, I'd sleep outside the bookstore like a groupie. Are you listening Mr Dunn??? Like a GROUPIE!! What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
If MS have any sense they will base any new unmanaged C++ framework on WTL - Borland couldn't compete back when they were a powerful player - remember OWL? - so they sure as hell won't be able to pull it off now. I always remember OWL vs MFC being like Betamax vs VHS - OWL (Betamax) was a more elegant framework, but MFC (VHS) had a lot more users and a lot more support behind it. Back in 1993, I asked my boss which framework I should start using as I was switching to C++ and he told me MFC was the way to go because Borland would eventuall lose the Windows C++ development war. He was right. As for MFC. Well, personally I don't care if MS never do anything more with it - I am happy for them to kill it off - as it won't make any difference to me in the slightest. I have two extremely large MFC apps that I still maintian/devlelop, but they use MFC42/MSVC6, both of which are already yesterdays news. MFC7 hardly added much functionality - all it did was create me a load of problems when I attempted to port my apps (so I could stick to one compiler using VS.200x). So I won't ever be using MFC7. Period. MFC served its purpose, and I think MS will continue to support it (i.e. the odd MSDN article and MFC7 service pack) but as my new apps are written using WTL, I don't care about MFC anymore. If I was a fresh-faced noob who wanted to write Windows apps using unmanaged C++ then I would go for WTL. It is probably easier to get to grips with if you haven't ever used MFC (and hence you have some mental "baggage")- and being template based, is for more elegant and extensible than MFC. I find it a joy to use - there is a learning curve, like anything, but I can hinestly say I am as productive now in WTL as I ever have been in MFC (lack of WTL ClassWizards aside!). Coupled with ATL7 it is hard to beat (and let's not forget that WTL is build on top of ATL - and ATL is very much a supported MS product - ATL7 added lots of new functionality). MS are currently scratching their heads over WTL as it getting more and more popular - a real conundrum for them to be honest. Do they give it their full support, enhance it and potentially distract people from .NET or do they leave it as is? Without "proper" support, many people won't want to use it - or many peoples bosses won't want them to anyway - and without this magic support, WTL will never be as popular as MFC was in its heyday. It needs a few decent books (Mr Dunn!), it needs some MSDN articles in order for many people to feel comfortable using it. Personally,
Robert Edward Caldecott wrote: It needs a few decent books (Mr Dunn!) Add my vote for that suggestion. I'm very surprised about the lack of decent resource and information on using WTL - especially when coming from MFC to WTL. I guess .NET got in the way. Michael 'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
-
A few posts down there is a link to a very interesting article on C++ and additions to the language. That got me thinking, on the future of C++ and application development. :confused: Although .NET is quite good (I really like C#, and APS.NET seems very nice as well), I feel that in the next few years there will still be a (big? :confused: ) need for 'unmanaged' code, especially C++. This for a number of reasons. Although .NET and JITers can be competitive when it comes to speed and such, there are (and will be) programs which would need C++ for optimal performance. Further, some people/companies are very skeptic on the whole MSIL and reverse engineering part. Because of this, and more, I think that unmanaged code, not only on Windows but other platforms as well, wil be in demand for quite som time. Only problem is that we need a "modern" application framework for this. The present choices do suffice at the moment, but are generally frowned upon. Especially when comparing them with modern products like .NET Framework etc. Some time ago (last month actually), Borland announced that they are in the process of developing a modern and Standard compliant croos-platform C++ RAD API product. Open Letter. When I read this, I thought GREAT. But then again, the last couple of years Borland has begun to fade away - so I'm not so sure if they can pull it off. I sure hope so. On the other 'side' there's MS. They still have MFC - and although I'm very green when it comes to MFC (I'm still learning it actually) I can safely say that it's not modern. They do have WTL though which seems really promising. At one of the microsoft.public newsgroups a guy from the MS VC++ compiler team said something to the extent of MS being surprised by WTL's big popularity, and maybe it'll be the basis for a new unmanaged C++ framework. :omg: So what about all this? Is the .NET MSIL reverse engineering threat exaggerated? Can the Borland adventure bring something good? Or should MS focus more on WTL as the future unmanged C++ framework? Or is all this irrelevant in the coming .NET future (if there is one)? Aynway, just me ranting probably...;P;P PS.: Sorry if this is not "Lounge material". But I didn't know where else to put it....:rolleyes::rolleyes:
I think you have absolutely no idea about WIN32 application development and deployment. MFC and WTL totally two different subject based on two DISTINCTIVELY different architect. Based on experienced using DUNDAS and ROGUEWAVE extended MFC, I can say MFC is still very strong. Native C++ remain strong in many area NOT only Windows. Microsoft should re-engineer MFC to better reflect the core of C++. Whether the new born MFC is based on class hierarchy or template is both fine to me. I just hope that native C/C++ development will continue as it is, instead of blending to some "un-manageable, incompatible" framework. :cool:
-
Michael P Butler wrote: Whilst there is a Win32 API there will always be an MFC. I wouldn't be so sure there will always be a Win32 API. For future OSes, I've heard that Microsoft is going to try to cut down the API, or make it only accessable through managed code/calls. If your nose runs and your feet smell, then you're built upside down.
Navin wrote: For future OSes, I've heard that Microsoft is going to try to cut down the API, or make it only accessable through managed code/calls. What about Longhorn? I keep hearing MS talk about the "extensive managed interfaces" in Longhorn. The question, then, is whether or not Longhorn will only expose managed interfaces or a combination of exposing unmanaged Win32 and managed calls. My guess is the latter, but who knows, maybe they'll write a .Net layer wrapping the entire Win32 API. Will be interesting to see what happens in 2005.
-
I'm not an expert on MFC, but I do remember that my week of playing with it ended with me running out of the house onto the street, naked and screaming armageddon with curlers in my hair. I think I made the mistake of having started out using raw Win32. I found MFC very frustrating. I read somewhere that MFC came about very quickly as a reaction to Borlands OWL having gained popularity, and as such it wasn't well designed from the start. In any case, I love WTL so what do I know? What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
Senkwe Chanda wrote: think I made the mistake of having started out using raw Win32. I found MFC very frustrating. I read somewhere that MFC came about very quickly as a reaction to Borlands OWL having gained popularity Oh, OWL who gives a hoot.. (booo) Anyway on a serious note, I started in raw Win32. After investing in code generators for the GUI because I was a lazy slob and did not what to type all that junk in all the time, I started using OWL. That is when I switched into high gear moving from C to C++. When MS put out MFC it was a joke compared to what I had already been doing with OWL. Did not see why anyone liked it. A while later Borland dropped the ball and left OWL users high and dry as they started to allow MFC into thier camp. By this time I was already fed up with the super buggy Borland 5.0 compiler and switched to VC and MFC. That was a huge change, but it did most of what I wanted it to do without totally boxing me in. The big problem though was the lack of Virtuals in MFC, it seemed like OWL had a lot more. I never had to go to the OWL source to pull out code and duplicate it because I run into a function that was not virtual ;) Of course all this was prior to the last year and half when I discovered and switched to .NET/C#. Again, I am a lazy boy and do not want to speed large amounts of time debugging or duplicating code that is already in .NET. I really enjoy .NET frameworks and the ease of use. I know I am just around the corner from moving to the rocking chair and retirement, but it is exciting to finally have change in the programming arena! As far as which to stay with, would depend on where you plan to work. Since most new Windows platform jobs are requiring at least knowledge of .NET, not to mention the vast number that are requiring a year of more experience in .NET, it would seem that speeks volumes. It also depends on where you reside. From what I have seen the vast majority of C++ jobs in the United States are for Linux/Unix. Rocky Moore <><