I hope, not. ;)
Oups, It's not my thread. I just have traveled in the past (my everyday's dream). :D
Printable View
I hope, not. ;)
Oups, It's not my thread. I just have traveled in the past (my everyday's dream). :D
I am a VC++ Developer working on VC++/MFC for last 2 yrs. After attending couple of interviews and company's requirements, what i've come across is most of the companies use SDK and pure C++ for developing core part of an application and for front end they prefer VC# or VB instead of MFC.
So i've started feeling bit insecure about my career. Since i want to stick into VC++ and my core strength lies in MFC. But since .net has arrived in the market it started making me feel bit insecure.
What do you guys think about MFC's present and future? When i say i want to stick into VC++ i didn't mean that i don't wanna learn .net languages, although combination of .net languages alongwith VC++ is the best combination. But i don't wanna totally move into .net from VC++.
Therefore career point of view what can you suggest me?
You might have a look at this thread.
You hope not, to satisfy yourself, but you are not sure about the truth. ovidiucucu it seems that you too are bit concerned about it. Am i right
Nope. If I have to use anything else, I don't mind.Quote:
Originally Posted by maverick786us
The Navajo native americans believe that someone dies only when the last person that remembers him/her dies. As long as people are still using MFC, MFC will not die. And currently many people are using MFC.
Nah, that was our little ghost in the machine scattering posts just for fun. :DQuote:
Originally Posted by Ovidiu
OK I am bit satisfied that MFC will not die. Even MS have the policy that he does'nt let his invention die that easily. But taking today's S/W market and future S/W market into the consideration, what will be the best choice for me.
For becoming a successful S/W developer, but in my past I have devoted myself for MFC in order to develop windows Based Applications. And the reason why VC++ is the most powerful language is because of its core programming, the ability which lets user directly interact with the H/W device, its registers etc, and MFC plays very short role in development of Core Application, its done using SDK, Win32 Porgamming and pure C++ etc.
What can you suggest me? I am good in MFC, i find it intresting but i am not a master in that. So in what else should i expertise myself besides MFC, Win32 Programming?
Despite being a VC++ Developer, has it become a need to learn .net language too? What are the best options available for me to have a stable career of S/W developer?
Recently I even read in this article
http://www.codeguru.com/forum/showth...1&page=2&pp=15
Stating that "For developing windows based application using MFC instead VC# is like using Assembly language for developing Win32 Applications". What openion do you guys have about it?
Thanks
Probably WinForms, WebServices, and the new stuff Avalon, Indigo, etc.Quote:
What can you suggest me? I am good in MFC, i find it intresting but i am not a master in that. So in what else should i expertise myself besides MFC, Win32 Programming?
The more you know, the better is.Quote:
Originally Posted by maverick786us
Blah!Quote:
Originally Posted by maverick786us
I fully agree... :DQuote:
Originally Posted by maverick786us
cilu what you suggested me, does that holds the future Software Market? I am very much worried about my career as a software developer and bit confused whether sticking to VC++ is right or move into managed code or do both.
Please tell me one last thing gstercken. Do you accept that Win32 with MFC is the strongest kind of programming technique available and is even more powerful than .NET or anything else today?Quote:
Originally Posted by gstercken
If so is it possible to combine Win32 with .NET like use an Win32 API to alter a control say in .NET. Is that possible if so please post a code fragment doing such a thing. Thanks.
... although, that comparison may sound wonderful in high-level programming language lovers (e.g. VB and so on) ears. :DQuote:
Originally Posted by gstercken
I wish to see the day when my boss will be alone and simply...
PS. "higher-level" programming languages doesn't mean "better" programming languages . ;)
You can do system programming as well as windows core programming through C/C++ and VC++ which i guess cannot be achieved through .net, although i am not sure.
According to my knowledge even 3-D Game development like Open GL Programming can only by achieved through C/C++/VC++
So after reading all the replies I wanna know what will be the best choice for my career as a successful software developer?
1) Move from VC++ and switch into .net?
2) Need to acquire thorough knowolege of VC++ as well as .net and combine them together to develop the application? (VC++ for core development and .net for windows interface and front - end development).
3) Stick to VC++ only, cuz there will always be the requirement of VC++ developers in today as well as future.
Is VC++ Career a successful and long lasting career?
Why i am asking all this is because its always hard to switch on to something new and start from scratchwhen you are into it for more than 2 yrs
Never stick in anything.Quote:
Originally Posted by maverick786us
Objection. I'm into C since 1984 now, into C++ since 1991, and I have been using MFC during the last 12 years. However, in my current project I use C# and the .NET 2.0 Framework (although it's still in Beta and will only be released two weeks from now), and we're already heading towards C#/.NET 3.0 / WinFX (WPF aka "Avalon", WCF aka "Indigo" etc.). So although I'm really deeply "into" MFC and it has been my favourite framework for writing GUI code on a daily basis for many years, when starting a new GUI app today I would never look back to MFC.Quote:
Originally Posted by maverick786us
In the IT world, you have to be flexible and willing to learn new technologies and paradigms every few years. You also have to understand when an era ends...
I know, these might be critical statements in a VC++ / MFC forum. Again, I'm far from saying that MFC is dead. MFC code will still be around for a very long time, the MFC library itself is being developed further, and there will always be a need for developers proficient in C++ and MFC. But your career chances will be far better if you additionally embrace new technologies instead of ignoring them. Besides that, and as said elsewhere: The entire managed / unmanaged interop story is becoming more and more important, so being an expert in both worlds is a very good idea IMO.
Nice speech [*applauding*]! ;)
BTW what about my question:
Is it possible to combine the .NET program with Win32 API??
Sorry, I had put you into the holding pattern... Please standby, I'll get back to your questions soon. ;)Quote:
Originally Posted by MrBeans
Once calling Win32 API is possible even from VB6 and older, why should be not possible from .NET/VB/C#?Quote:
Originally Posted by MrBeans
I have asked the dotnetgurus around me and they said: "possible" plus "ughh".
oh thanks ovidiucucu, I did not think in that direction at all :ehh:
Anyway I am on standby :D waiting for gstercken reply.
I know, I know. Just was shooting in the dark. :)Quote:
Originally Posted by MrBeans
It depends on what you mean by "strong" and "powerful". If that means "getting most work done in a highly productive way with least possible coding and risk of errors", then certainly not. If, OTOH, by "powerful" you mean the ability to write low-level code which deals directly with processor registers or implement your own memory manager, then C++ is certainly more "powerful" (although MFC won't help you much here either). Just wondering: When was the last time you actually had to do this kind of things?Quote:
Originally Posted by MrBeans
Of course, that's what interop is all about. The most common ways to do this is to either use COM interfaces (which you can directly call from managed code) or to use C++ (which is currently the only high-level language that lets you mix managed and unmanaged code).Quote:
Originally Posted by MrBeans
A few years ago, when all the world was talking about COM and ActiveX, I also adopted them (I had to, since projects at that time required it), although I have never been convinced of them. And although some of the concepts (especially the idea to use interfaces extensively) have survived and can be found in .NET today, diving so deep into that complex and clumsy technology has been a waste of time in the long run.
When the Java hype started, I luckily managed to get almost completely around it (the most important stuff I lately did with Java was porting Java apps back to C++ / MFC, because customers didn't want to see Java code any longer in their projects for various reasons).
However, C# (as a language) and .NET (both the CLR/CTS and managed code as a technology and the framework itself as a class library) feel completely different, and I predict them a great future. I'm really looking forward to reading these statements again 5-10 years from now... Let's see what the future brings!
It is, but as a rule of thumb try make calls to Win32API from your managed code only when absolutely necessary. The interop overhead can prove significant for the speed of your app.Quote:
Originally Posted by MrBeans
OK. Cool Guys.
Is MFC Finished?is the market is changed?
These all questions come to software fields every day.Only as gstercken said "adapt to new things" is the only solution.
"MFC has many different strong points compared to VB like owner-drawing etc."
Upgrade urself and be smart . That's it..
I am working for more than 6 years in this field and I have seen work coming in all the times.
Also some new companies are using MFC for their products too. They use the .net platform editor and use MFC.
I guess its just a timepass debate. Nothing is going to happen to good old MFC which revolutionized the windows based development industry.
As a little aside observation:
All successful and good (successful doesn't always mean good so "and" is mandatory) programming languages creators (e.g. Kernighan, Ritchie, and Stroustrup) had beard at the moment of creation.
The creator of C# had not. :D
Well, we'll see... maybe there are just statistics...
How about Turbo Pascal? Already way back then, Anders Hejlsberg had no beard... ;)Quote:
Originally Posted by ovidiucucu
Well, well, well!...Quote:
Originally Posted by gstercken
You have paid no attention or deliberately have ignored that mandatory "and". :D ;)
:D Just wondering whether you consider Turbo Pascal bad or unsuccessful...? ;)Quote:
Originally Posted by ovidiucucu
Hard to decide which one. :DQuote:
Originally Posted by gstercken
But few time ago I had to write some Pascal code and got tired writting tens of BEGIN/ENDs. :)
Despite that, it's not me the guy who created Death to Pascal. ;)
Well, I've nothing against Pascal.
Just to note that need long white beard until return to Pascal again. ;)
I remember when moving from Pascal to C it was "fashionable" to define BEGIN/END. :DQuote:
Originally Posted by ovidiucucu
Code:#define BEGIN {
#define END }
Returning a bit to the topic I think that reducing your skills to a single language and a single framework is dangerous. I don't say .NET is better than C++ & MFC or viceversa, because it is like comparing apples to pears. There is no universal solution to all IT problems. Some things are best done in C++ while for others VB is the faster solution .
If you need some quick Graphical App that simply reads some data from a database, .NET is definitelly a better/faster approach than C++. On the other hand, C++ is a much better option for an encryption library/HTTP server.
Each and everyone has the right to like a language/technology. For me, the .NET although younger and sexier ;) is no match for the good old C++
Well it's strong to agrue against a technology that is easy to learn and works on different plat forms. C# and Java promise that.
MFC has it's place, but no matter how you cut it, it's pretty much a Windows platform development technology, yet the compiler's organization tool are great for C/C++ general development.
However the abity to take ANSI C/C++ and create a windows app has it's place.
.. I guess what I'm saying is that if you are doing C/C++ in a Windows platform it's hard to agrue against MFC.
But now that Java ( I don't know how extensivly MICROSOFT has created multi platform support for C#) provides strong multiplatform support it's difficult to agrue against it.
MFC has it place but I don't think it will ever have the strong market share it once did.
In my opinion VB, JAVA, ASP and C# are all languages that should be spoken by today's developer. MFC is a great development library and in my opinion the best library out there for windows development in C/C++ but it's not enough in today's computing world.
In my opionion VB and JAVA should be in every MFC developers tool box. Unfortiontly MFC is only a WINDOWS developement tool.
Now if Microsoft would create some kind of compiler that generated cross platform BYTE-CODE, that would definatley increase it's popularity ( I haven't heard of such a beast). But that would be awesome if they created such product. There is a lot of MFC out there, that is probobly being re written to C# and JAVA.
Excuse , I also wanna deliver my opinon here .
No, existence of life with MFC should depend on how many programmers are using it including frequence degree for use it . Of course , that may depend on the update version MFC that can help us to be much easier & conveniently to use with more powerful function. Also, sometimes effect for everyone is still important . as that will promote good spirit to encourage someone who is not using MFC to use it .Quote:
Is MFC Finished ...????
If you still worry about your carrer now , to learn pure C or C++ language is also a good way to do what you want. As many many programmers in the world can do some excerlent projects with using pure C or C++ instead of using MFC , @Microsoft is a good model.
In any case , to do what you like is always right , no need to worry about any . and you have to believe the whole world is in progress ......
Quote:
Originally Posted by gstercken
Well I do agree that creating a GUI in .net (C++/C#) is a lot easier and I do like the Mask control that comes with Visual C++ .NET. That was always my grip with MFC/WIN32 that you had to create your own mask edit control.
A functional understanding of MFC however is a great stepping stone to .NET technologies.
Yes , ADSOFT guy's saying is right , to use VS.Net be is a lot easier to do something , but if we do like this all along , maybe there will have one problem to face, that is , what can we do without using MFC or like VS.Net etc, right ?
In any case , I think that , to master C/C++ & VC++ or VS.Net is a wise choice , even if there is no MFC , we still do something just like using MFC, right ?
Well if you read this post, you will see why MFC is definatly not dead, and just might increase in popularity in the future.
http://www.codeproject.com/managedcp...ogWinForms.asp
That's a nice article. ... this was always my gripe with MFC lack of a MaskedEdit control. Just search this forum for how many times I asked for a good masked edit class.
MFC deserves to die. It is a bad foundation.
Before MFC, if you wanted to write a desktop application, you had to deal with a monolithic switch statment handling the hundreds of messages that your app needed to process. MFC gave us an application framework, a real one, based on the Document/View paradigm, which, for a desktop application that is more than just a front end to a database with the ui being a dialog window (okay a windows form) with some buttons and text boxes, still cannot be touched by .NET. Until .NET comes up with a decent application framework, MFC will remain entrenched by default, in the case of desktop applications, of which there is still great need. Not everything is a .NET asp application. There are other forms of programming, Microsoft.
However, underneath it all, the Win 32 library functions, I believe, are still written in C. The win 32 functions are written in C, and the GDI objects are some kind of hokey conglomeration utilizing C.
Go ahead .NET. Have a blast with that!
MFC, it's ugly but it's still the best we have!
That sounds as if in your opinion the masked edit control was the only benefit of the .NET framework. How about the auto layout controls, such as the table layout panel, the flow layout panel and the split panel? How about tool strip and menu strip containers? Automatic scrolling? How about the GDI+ for drawing (instead of the old-fashioned GDI)? Or the automatic use of offscreen bitmaps by simply setting a property value? Not to mention the power of reflection and CodeDOM, the Decimal data type, the full-fledged support for localization, the easy way of creating and using fonts, the almost automatic support for application settings, the extensible built-in XML and binary serialization support? Data binding? The incredibly improved handling of tree controls and list controls by finally exposing their items as objects instead of handles? I could go on like this for hours - and, as already said above: Although I have been using MFC since the very beginning, and MFC has been "my" domain for many years: After having used C# and .NET 2.0, I would never look back to MFC again. The possibility to mix MFC and .NET (as in the article you quoted) is a nice feature when you have to deal with legacy MFC code. But I will never start a new project based on MFC if I have the choice. The whole .NET world is soooo much more productive.Quote:
Originally Posted by ADSOFT
Again: All this doesn't mean that MFC is "dead". Nothing is dead - even assembly language still has its raison d'être where appropriate. However, with the advent of .NET, MFC and unmanaged C++ are technologies of the past. They will still be supported by Microsoft, they will even be developed further - but their importance for the mainstream of software development under Windows is steadily decreasing.
Quote:
Originally Posted by gstercken
Well, I agree with everything you have said. But I'm a little confused. It's as if you got mad that I didn't praise all the other features.
And I'm glad that we are in agreement that the post I added above is a promising feature of the new MFC.
But to be honest with you, it's as if Microsoft stuck it to the C++ programers again.
Visual Basic was a slap to the C++ progamers because the productivity of and expertise to get a VB app up and running versus what it took for a person experienced in C/C++ was night and day. The masked edit control, the lack of an ability to change the font size on a label at design time, and the difficulty of printing really slowed the learning curve of VC++ MFC develepment even for an experienced C/C++ programer.
C/C++ programers got slapped again when VB.net and C# .net both got gui designers and not VC++ .NET (2002 edition). Again all legacy c/c++ code had to wait to get a gui that was productive.
Now with the advent of VC++ .NET Microsoft has finally addressed the needs of C/C++ programers that like C/C++ and want to develop Windows products.
I was very pleased to be able to cut/paste some legacy code in VC++ .NET and have it fire up and compile. It was cool to port some ANSI C/C++ code to VC++ .NET and get a gui up and running. ... I guess all the ansi C/C++ code could be cut and pasted to VISUAL C++ .net also, so port over an app wil not be a totall rewrite.
So there might be a Market for MFC programers converting code to VC++ .net , since it supports C/C++ . .. MFC code can be ported .NET c/c++ at your own pace with the Enterprise editions as the above link menstions, yet I don't know if it can be done with the other versions (except the express edition). i.e. ....
For those who invested the time to use MFC they can continue, and adopt the .NET at their pace.
MFC could use some enhancements though. I for one would like to see it's own mask edit control . With the intergration of .NET C/C++ I think it's obvious that MFC programers of the future will be able to write their windows apps in SDK(Win Api), MFC, VC++ .NET(Winforms). It's just another library to learn and will gaurenttee that .NET technology can easily be intergrated to legacy apps.
But yes I agree, VISUAL C++ .NET(Winforms library) is going to be a must for MFC & C++ programers. I like the Gui designer in .NET C++. If you want to continue with MFC I think the final Wake-UP call to develop MFC intergrated with Visuall C++ .NET (Winforms) has been rung with the 2005 VS and Express family sets. C# and intergrating MFC with .NET technologies is going to be a must for MFC programers. If you havent' started with Visual C++ .Net you are already behing.
I guess if your going to call yourself a Windows C/C++
You will have to know SDK/MFC/ATL/.NET at least.
If .NET keeps catching on the way it does, who knows, Visual Studio 2008 Professional might be had for 500 bucks! ;)
Seriously, though, they need to come up with an application framework for us desktop guys (oh, excuse me....smart clients).
I started learning C#, then stopped. It is simply too painful to look at the apps that were used for explanatory purposes. Just too romper room for my tastes. Are there real desktop programs being generated with .NET that arent' just web apps? Please point to example. I'm serious.
Just to set the context for my last post. These are the kinds of apps that I write:
http://members.aol.com/spiritualfiel...screenshot.htm
This one is pure MFC, with a flat file database that I have absolute control over because I created it myself. I can make that thing whistle dixie and scoop the poop if I want!. The view is drawn in, the screen is not a collection of edit boxes, but lines arranged to look like edit boxes. Functionally, to a user, there is no difference between an edit box control and my, for lack of a better word, "text rectangles" lol! The main thing is that the database was perfectly encapsulated by the CDocument, yet seamlessly integrated with the document's CView. I just don't get the idea that I can write this kind of an app with .NET., and I'm not really a control user freak, as I lose control of my app with every whizbang I include. I draw the lines with buttons, edit controls, combo boxes, which are for my dialog windows. There are some classes in .NET that look appealing but they are outside of the GDI+ class. Perhaps if there is a decent C++ book that comes out that goes into .NET, I'll give it another try.
Well I'm not not MFC expert yet I have written many simple apps and ported them. Most of the stuff I have written are utilities, porting of legacy code, maintainace of MFC and ACCESS database stuff.
.. my two biggest road blocks with MFC where the lack a mask edit control (wich I finally to the time, 3 weeks to write), and writing patchup code for Access database to make it more stable and simulate true record-locking.
Yet, there is a book VISUAL C++ step by step from Microsoft that goes through process of developing a VISUAL C++ app using WINFORMS. It's pretty easy and if you know MFC it's a cake walk since you don't have all the macros that you have in MFC.
The Gui designer is cool too. Last I read when I was doing the research on it you can compile VISUAL C++ .NET code to native code. ... I could be wrong.
I haven't found any good books that to develop "smart client apps" in VISUAL C++, but I think if you know MFC and pickup VISUAC C++.NET step by step you will beable to put it all together.
Here is some reassuring information about MFC:
http://msdn.microsoft.com/visualc/wh...5/default.aspx
Personally, I don't think that .NET will ever see a document view architecture because the designers of .NET had the web in mind, not the desktop. And why re-invent the wheel anyway? So my guess is that true blue desktop app programmers will stick with MFC and haul in whatever them deem useful from .NET, as each unique situation warrants.
Microsoft made a big mistake in the way they rolled out .NET. It was so poorly integrated with C++ that I wonder about the sanity of that .NET design team. And I still have my doubts. Fortunately, saner minds seem to be seeping in that organization. When I see C++ being mentioned in the same breath as C#, then I'll know that their ship has righted.